<HTML><HEAD> <META content=IE=5 http-equiv=X-UA-Compatible> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <STYLE id=mysingle_style type=text/css>.search-word { BACKGROUND-COLOR: #ffee94 } P { FONT-SIZE: 10pt; MARGIN-BOTTOM: 5px; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px } TD { FONT-SIZE: 10pt; MARGIN-BOTTOM: 5px; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px } LI { FONT-SIZE: 10pt; MARGIN-BOTTOM: 5px; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px } BODY { FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial } </STYLE> <STYLE id=knox_style type=text/css>P { FONT-SIZE: 10pt; MARGIN-BOTTOM: 5px; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px } </STYLE> <META name=GENERATOR content=ActiveSquare></HEAD> <BODY style="OVERFLOW: auto"> Hi, On 10 Sep 2020 at 08:02, David Rheinsberg <<A href="mailto:david.rheinsberg@gmail.com">david.rheinsberg@gmail.com</A>> wrote: > On Thu, 10 Sep 2020 at 01:21, Hailun Tan <<A href="mailto:dearambermini@gmail.com> wrote:">dearambermini@gmail.com> wrote: </A>>> 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 <table id=bannersignimg data-cui-lock="true" namo_lock><tr><td> </td></tr></table><table id=confidentialsignimg data-cui-lock="true" namo_lock><tr><td> <img style="border: 0px solid currentColor; border-image: none; width: 520px; height: 144px; display: inline-block;" unselectable="on" data-cui-image="true" src="cid:cafe_image_0@s-core.co.kr"> </td></tr></table></BODY></HTML><img src='http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=adrian.s&do=bWFpbElEPTIwMjAwOTExMDkwMzMwZXVjbXMxcDM2MWJmYmIwZmYyZjBkMTQ5MmEyN2FhN2QwYjc4ZGNiOCZyZWNpcGllbnRBZGRyZXNzPWRidXNAbGlzdHMuZnJlZWRlc2t0b3Aub3Jn' border=0 width=0 height=0 style='display:none'>