Re: Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 19.02.21 08:44, Ulrich Windl (Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx) wrote:

> >>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel