From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12983 Path: news.gmane.org!.POSTED!not-for-mail From: ritesh sonawane Newsgroups: gmane.linux.lib.musl.general Subject: Re: Changing MMAP_THRESHOLD in malloc() implementation. Date: Wed, 4 Jul 2018 12:35:02 +0530 Message-ID: References: <20180703144331.GL1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000bdffda0570270caa" X-Trace: blaine.gmane.org 1530687795 31607 195.159.176.226 (4 Jul 2018 07:03:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2018 07:03:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12999-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 04 09:03:11 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 1faboj-00084S-J5 for gllmg-musl@m.gmane.org; Wed, 04 Jul 2018 09:03:09 +0200 Original-Received: (qmail 5422 invoked by uid 550); 4 Jul 2018 07:05:16 -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 5394 invoked from network); 4 Jul 2018 07:05:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=QZDmZnWOjDUCEm4/jq86GcqDtyL3sjMP7jNRP/vGC30=; b=rGOOGk82bIUlBrrzA7Q0FavqT+k2ijHKvmOAd3yN5/eCeTjmcYaLzIqqkk23zp4wX0 8aKuVDznc/SnmAk6DPGY4YndKZ/d0Hf5W8n/zWsSYVxhwYnXYHqIo4OLk1dCViPp3lGq iosW46+N7iRLYtSKGI+xbONLDPNSTIvOQyY2+BMl4BohbDtaUOC5pAb1wkJkxsoKBoS+ WFvi2BZOEtZO5dNZNSIHW0pku4HAGniqSIf9WLwQgkCmHMMb+oYbE8XAg95q/LBhdv+C Cx5SBVC2hTDGjJXbE3CzoH5Z+tki0VHBd6QDtAOnnrWp4wEFqixUzD6yYdgnEMzIPW8m YPIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=QZDmZnWOjDUCEm4/jq86GcqDtyL3sjMP7jNRP/vGC30=; b=ImuCZcLpiZM4/eWiM4MBcKjX7LmIeDFAKK9lzl47RmDgsxxf4Pja7fjhIqCS3sZ6R3 NpO9aAQwGtpOHp+Icp3fckNVqUlpCgWAL+rofGe6nO9mdWgHG1hopkYj7xFBOQU8dRX/ S8Fcna7MhoGRVeRi9Qdjg+6CDwMrRRqBBX96xEc4Ahgh6bJqj11Oe0Bu7bKmITILo7XU yqx76DmQJP00T3oJxXllPf06dCwC1GFAzHnOqi2w/RgQdHJgMg7lBVS7gkEXYnjPtYM8 BRlaoNRJe6k9suF63g8EikvhaxolcLHrDUsFIZTXLC81VJXO8yRbhgw9A2GxcceYjUrk 8jeg== X-Gm-Message-State: APt69E1n6hepu+wzPuqglgJ0ZNBneOLn6+iNAnqCRkdNW96IfAC/G54/ tQ/CYYnvKBIBjhXJOKBkDJbT5WHFPNJdmT+vK7U= X-Google-Smtp-Source: AAOMgpeAuUSHU9BjXPjm4nMQVj2onyW0cgi3K+WCO9vkJp4uQT//4XRdGMuAKByjCjgtsY4kuasM8G+fPcrVuFUBvbo= X-Received: by 2002:a6b:d106:: with SMTP id l6-v6mr580726iob.8.1530687903365; Wed, 04 Jul 2018 00:05:03 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:12983 Archived-At: --000000000000bdffda0570270caa Content-Type: text/plain; charset="UTF-8" sir above statistics are with 64MB page size. we are using system which having 2MB(large page) 64MB(huge page). On Wed, Jul 4, 2018 at 10:54 AM, ritesh sonawane wrote: > Thank you very much for instant reply.. > > Yes sir it is wasting memory for each shared library. But memory wastage > even worse when program > requesting memory with size more than 224KB(threshold value). > > ->If a program requests 1GB per request, it can use 45GB at the most. > ->If a program requests 512MB per request, it can use 41.5GB at the most. > ->If a program requests 225KB per request, it can use about 167MB at the > most. > > As we ported musl-1.1.14 for our architecture, we are bounded to make > change in same base code. > we have increased MMAP_THRESHOLD to 1GB and also changes the calculation > for bin index . > after that observed improvement in memory utilization. i.e for size 225KB > memory used is 47.6 GB. > > But now facing problem in multi threaded application. As we haven't > changed the function pretrim() > because there are some hard coded values like '40' and '3' used and > unable to understand how > these values are decided ..? > > static int pretrim(struct chunk *self, size_t n, int i, int j) > { > size_t n1; > struct chunk *next, *split; > > /* We cannot pretrim if it would require re-binning. */ > if (j < 40) return 0; > if (j < i+3) { > if (j != 63) return 0; > n1 = CHUNK_SIZE(self); > if (n1-n <= MMAP_THRESHOLD) return 0; > } else { > n1 = CHUNK_SIZE(self); > } > ..... > ..... > ...... > } > > can we get any clue how these value are decided, it will be very > helpful for us. > > Best Regard, > Ritesh Sonawane > > On Tue, Jul 3, 2018 at 8:13 PM, Rich Felker wrote: > >> 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 >> > > --000000000000bdffda0570270caa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
sir above statistics are with 64MB page size. we are using= system which having 2MB(large page)=C2=A0
64MB(huge page).
=

On Wed, Jul 4, 20= 18 at 10:54 AM, ritesh sonawane <rdssonawane2317@gmail.com>= wrote:
Thank you= very much for instant reply..

Yes sir it is wasting mem= ory for each shared library. But memory wastage even worse when program=C2= =A0
requesting memory with size more than 224KB(threshold value).=

->If a program requests 1GB per request, it ca= n use 45GB at the most.
->If a program requests 512MB per = request, it can use 41.5GB at the most.
->If a program request= s 225KB per request, it can use about 167MB at the most.

As we ported=C2=A0=C2=A0musl-1.1.14 for our architecture, we are bou= nded to make change in same base code.
we have increased=C2=A0 MMAP_THRESHOLD to 1GB and also changes the calculation for bin index .
after that observed improv= ement in memory utilization. i.e for size 225KB memory used is 47.6 GB.

But now facing problem in multi threaded app= lication. As we haven't changed the function=C2=A0pretrim()=C2=A0
because=C2=A0there are some hard coded values like '40' a= nd '3' used and unable to understand how=C2=A0
these values are decided ..?

static int pretrim(struct chunk *self, size_t n, int i, int j= )
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t n1;<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stru= ct chunk *next, *split;
<= br>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 /* We cannot pretrim if it would require re-binning. */
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (j <= ; 40) return 0;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 if (j < i+3) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (j= !=3D 63) return 0;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n1 =3D CHUNK_SIZE(self= );
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (n1-n <=3D MMAP_THRESHOLD) return = 0;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 } else {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 n1 =3D CHUNK_SIZE(self);
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
=C2=A0.....<= /div>
=C2=A0.....
......
}

can we get any clue how these value are decided, it will be very helpfu= l=C2=A0for us.
=C2=A0
Best Regard,
Ritesh Sonawane

On Tue, Jul 3, 2018 at 8:13 PM, Rich Felker <dalias@libc.or= g> wrote:
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 pa= ge
> size of 2MB.
> Due to low threshold value there is more memory wastage. So we want to=
> change the value of=C2=A0 MMAP_THRESHOLD.
>
> can anyone please giude us, which factor need to consider to change th= is
> 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


--000000000000bdffda0570270caa--