Re: Control on DBus-daemon virtual memory usage ballooning

Hi,




On 10 Sep 2020 at 08:02, David Rheinsberg <[email protected] > wrote:
> On Thu, 10 Sep 2020 at 01:21, Hailun Tan <[email protected]> wrote: wrote:>>> It mentioned that D-Bus never freed its data.
>
> The dbus-daemon process uses memory-management like any other common
> Linux process. The memory-allocator is taken from glibc. This
> allocator reserves a pool of data which it hands back to the kernel
> only when fragmentation and usage permit it.

I think the internal memory pools, managed by DBusMemPool, may be involved here.




A pool block is allocated if existing blocks are full. Each newly allocated block is twice as big as previous. Blocks are freed all at once, *only* when *all* of them are empty.




I've found these pools:


1. registry pools (service_pool and owner_pool) - they are freed only when the daemon exits;


2. DBusHashTable pool - it is freed with its hash table;


3. the list_pool (the global one) - it contains list links, and there is always some list link allocated somewhere, so the pool is never empty, so it's never freed.




If 1 and 3 grow, they stay "large" for the daemon's life.




Recently, we've noticed that kind of interaction between the list_pool and a "freezer": a process may be frozen (e.g. for energy saving), and if it's the destination of some messages (e.g. signals), the list_pool grows to keep links for lists holding the messages. When the process wakes up, it handles the messages, but the list_pool never shrinks, it just gets "near empty".




I guess it's a tradeoff: simplicity + performance vs. one-way memory street.




Kind Regards,


Adrian

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus