From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12977 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Changing MMAP_THRESHOLD in malloc() implementation. Date: Tue, 3 Jul 2018 10:43:31 -0400 Message-ID: <20180703144331.GL1392@brightrain.aerifal.cx> References: 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 1530628903 30671 195.159.176.226 (3 Jul 2018 14:41:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Jul 2018 14:41:43 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12993-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 03 16:41:39 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 1faMUq-0007oZ-L9 for gllmg-musl@m.gmane.org; Tue, 03 Jul 2018 16:41:36 +0200 Original-Received: (qmail 13369 invoked by uid 550); 3 Jul 2018 14:43:44 -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 13348 invoked from network); 3 Jul 2018 14:43:44 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12977 Archived-At: On Tue, Jul 03, 2018 at 12:58:04PM +0530, ritesh sonawane wrote: > Hi All, > > We are using musl-1.1.14 version for our architecture. It is having page > size of 2MB. > Due to low threshold value there is more memory wastage. So we want to > change the value of MMAP_THRESHOLD. > > can anyone please giude us, which factor need to consider to change this > threshold value ? It's not a parameter that can be changed but linked to the scale of bin sizes. There is no framework to track and reuse freed chunks which are larger than MMAP_THRESHOLD, so you'd be replacing recoverable waste from page granularity with unrecoverable waste from inability to reuse these larger freed chunks except breaking them up into pieces to satisfy smaller requests. I may look into handling this better when replacing musl's malloc at some point, but if your system forces you to use ridiculously large pages like 2MB, you've basically committed to wasting huge amounts of memory anyway (at least 2MB for each shared library in each process)... With musl git-master and future releases, you have the option to link a malloc replacement library that might be a decent solution to your problem. Rich