From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 51D0D385703B; Tue, 1 Dec 2020 02:51:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 51D0D385703B From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug malloc/26969] A common malloc pattern can make memory not given back to OS Date: Tue, 01 Dec 2020 02:51:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: malloc X-Bugzilla-Version: 2.27 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: NOTABUG X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 02:51:10 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26969 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Carlos O'Donell --- The glibc implementation of malloc is a heap-based allocator and in that de= sign the heap must be logically freed back down in the order that it was origina= lly allocated or the heap will continue to grow to keep a maximum working set of chunks for application. If you want to free back down to zero at the last deallocation you must tune the allocator by disabling fastbins and tcache. For example: - Allocate A - Allocate B - Allocate C - Free A - Free B - Free C Consider A, B and C are all the same size. Until "Free C" happens the entire stack is held at 3 objects deep. This can happen because tcache or fastbins holds the most recently freed ch= unk for re-use. There is nothing wrong with this strategy because the C library, apriori, doesn't know if you'll carry out this entire workload again. The worse-case degenerate situation for tcache is a sequence of allocations which cause tcache to always hold the top-of-heap chunks as in-use. In a re= al program those chunks are refilled into the tcache much more randomly via ma= lloc from the unsorted bin or small bin refill strategy. Thus tcache should not = keep the top-of-heap from freeing down in those cases. It's only in synthetic te= st cases like this where I think you see tcache being the blocker to freeing d= own from the top of heap. If you need to free pages between workloads and while idle you can call malloc_trim() to release page-sized consolidated parts of the heaps. If you need a minimal working set, then you need to turn off fastbins and tcache. One possible enhancement we can make is to split the heaps by pool sizes, a= nd that's something I've talked about a bit with DJ Delorie. As it stands thou= gh that would be a distinct enhancement. I'm marking this as RESOLVED/NOTABUG since the algorithm is working as inte= nded but doesn't meet your specific synthetic workload. If you have a real non-synthetic workload that exhibits problems please open a bug and we can = talk about it and review performance and capture an API trace. --=20 You are receiving this mail because: You are on the CC list for the bug.=