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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> 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.

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



_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux