Re: [systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces
On Fr, 19.02.21 08:44, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Lennart Poettering schrieb am 18.02.2021 um 19:30 > in > Nachricht : > ... > > 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
Re: [systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces
Am 19.02.21 um 08:44 schrieb Ulrich Windl: Lennart Poettering schrieb am 18.02.2021 um 19:30 in Nachricht : ... 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 following that logic every memory pool and mysql buffer would be a memleak a memleak is *unintended* and never freed memory allocation, practically as well as theoretically you can argue about the size of such cases but it don't make them a memleak to begin with ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces
>>> Lennart Poettering schrieb am 18.02.2021 um 19:30 in Nachricht : ... > 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. > > You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off, but > not sure v230 already knew that env var. > > Lennart > > ‑‑ > Lennart Poettering, Berlin > ___ > systemd‑devel mailing list > systemd‑de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd‑devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
