On Fr, 19.02.21 08:44, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering <lenn...@poettering.net> schrieb am 18.02.2021 um 19:30 > in > Nachricht <YC6yQIX+7MFLvhmc@gardel-login>: > ... > > entry instead of asking for new memory again. This allocation cache is > > a bit quicker then going to malloc() all the time, but means if you > > just watch the heap you'll assume there's a leak even though there > > isn't really, the memory is not lost after all, and will be reused > > eventually if we need it. > > That's an interesting point of view: If you save memory in case you might need > it at some unspecified later time (which includes "never") it's "practically" > (while not theoretically) a memory leak. Allocation caches are a common technique. In systemd, but everywhere else too. glibc's malloc() itself is one too actually (i.e. it's a cache in front of kernel mmap()/sbrk()). Internally in the kernel there are multiple different allocation caches in place as well. If you have an issue with allocation caches, I am sorry, but modern Linux kernel and userspace is not for you. Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
