From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12708 Path: news.gmane.org!.POSTED!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC PATCH] reduce severity of ldso reclaim_gaps hack Date: Thu, 12 Apr 2018 09:40:23 +0300 (MSK) Message-ID: References: <20170628165243.16502-1-amonakov@ispras.ru> <20180411201057.GO3094@brightrain.aerifal.cx> <20180412040408.GP3094@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1523515135 19662 195.159.176.226 (12 Apr 2018 06:38:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Apr 2018 06:38:55 +0000 (UTC) User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) To: musl@lists.openwall.com Original-X-From: musl-return-12724-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 12 08:38:51 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f6Vsh-00050J-5U for gllmg-musl@m.gmane.org; Thu, 12 Apr 2018 08:38:51 +0200 Original-Received: (qmail 14157 invoked by uid 550); 12 Apr 2018 06:40:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 14138 invoked from network); 12 Apr 2018 06:40:58 -0000 In-Reply-To: <20180412040408.GP3094@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12708 Archived-At: On Thu, 12 Apr 2018, Rich Felker wrote: > > > This does not seem necessary. Free chunks in the last bin can be > > > larger than MMAP_THRESHOLD; they're just broken up to satisfy > > > allocations. Of course it's unlikely to happen anyway. > > > > Do such oversized chunks appear in normal operation? This seems non-obvious, > > so a comment pointing that out would probably be helpful. > > The only way I could see it happening is on an arch ABI that allows > very large pages (and has the ELF load segments aligned accordingly, > as x86_64 does). In this case if the kernel/hardware only supported > large (e.g. 2MB) pages, you'd pretty much always end up with >1.5MB of > reclaimed space per DSO. IMO this is an awful kernel/hardware > constraint to have, very wasteful, but it's exactly the situation > where you'd most care about the gaps getting reclaimed for something > useful. What I meant to ask is: apart from chunks created via reclaim_gaps, can such oversized chunks appear as a result of malloc-family calls invoked by the program? Alexander