From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4776 Path: news.gmane.org!not-for-mail From: "M. Ziebell" Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc & uncommitting memory Date: Thu, 3 Apr 2014 20:17:25 +0200 Message-ID: <20140403201725.7509341f@MG> References: <20140402210805.GA852@brightrain.aerifal.cx> <20140403044323.GR26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/0+fu2zz6_89SaRTEFZ_hgAl"; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1396549392 23380 80.91.229.3 (3 Apr 2014 18:23:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2014 18:23:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4780-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 03 20:23:06 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WVmI5-0003OW-Fh for gllmg-musl@plane.gmane.org; Thu, 03 Apr 2014 20:23:05 +0200 Original-Received: (qmail 22209 invoked by uid 550); 3 Apr 2014 18:23:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18334 invoked from network); 3 Apr 2014 18:18:03 -0000 X-Virus-Scanned: amavisd-new at posteo.de In-Reply-To: <20140403044323.GR26358@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:4776 Archived-At: --Sig_/0+fu2zz6_89SaRTEFZ_hgAl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 3 Apr 2014 00:43:23 -0400 schrieb Rich Felker : > On Wed, Apr 02, 2014 at 05:08:05PM -0400, Rich Felker wrote: > > As long as thresholds are chosen right, I don't think this approach > > would be costly from a performance standpoint. But it might have > > consequences for fragmentation. So I'd like to discuss it further, > > see what ideas emerge, and whether it looks reasonable before > > trying to implement anything. >=20 > Basically, the way fragmentation can result from having "frozen" > chunks is when small chunks adjacent to them are freed: these free > chunks are unable to be merged with the frozen chunk, so they get > reused for small allocations despite being adjacent to a large free > (albeit frozen) region. >=20 > I see several possible ways to reduce or avoid this: >=20 > 1. Always leave large padding (large enough to stay in bin-63) on both > sides of the frozen chunk when freezing. This would force adjacent > freed chunks to get merged into a bin-63 chunk, preventing them > from getting used for small allocations unless nothing smaller were > available. However, they could still get used and gradually > depleted. >=20 > 2. When a chunk is freed, check if it's a neighbor to a frozen chunk, > and if so, put it at the end of its bin rather than the beginning, > so that other free chunks of the appropriate size get used first. > However this wouldn't help when it's the only chunk of its size but > another slightly-larger chunk would be a better candidate to split. >=20 > 3. Allow merging directly into frozen chunks, the same way merging > into free chunks is done now, with logic to expand the region > that's PROT_NONE similar to the current logic for expanding the > MADV_DONTNEED region. >=20 > Of these, option 3 looks the most promising. >=20 > Rich As far as i understand "uncommitted" memory is allocated address space. A region in memory which is not used by the program, but the address space expanded to make a smaller region available to the programm for use. Please correct me if I am wrong. Based on that understanding, the idea or your proposal sounds not really desirable. You have to take care of tons of exceptions and special cases. I'm pretty sure I don't understand what uncommitted memory is for, but I'm heary is hundreds of lines of complex code, if-else constructs everywhere and bugs. The way you suggest to manage these regions in memory sound pretty and advanced, please don't feel offended by my statement.=20 Marco --Sig_/0+fu2zz6_89SaRTEFZ_hgAl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTPaW8AAoJEJvazhohxj7E5UsIAIsZUI1ARLDWVAvoZCSPZKWk 5m+HuYsm2zEVB6xQpw5w8fuKH8eiEqWcNY2L7k4vL92BRnCZ3Z/ivtk5zcS3WEdV k2l/IHTy/h8xyQSDap6hLRxToItqEByc2eBeqtss3IdwsNLbd7BFBj4UsQHMbr37 bSTAGWaO8msm9zgLrdoJSmcoJmoUI2GT1XslxPBQEfwPMutHr9ydjCItKnsYMpCd srnWp+iR5lDLA7dG2NAlbLvEhIvPVsk30NU3XV9SvN1zxVIptj7m7CsNNLSbqR1g Hp9UnIY1hUKFu2YiyzOJW9fvet144HhXJRRTKIbFv460w6ZkxE3F/ZTqmShgG3k= =ndRG -----END PGP SIGNATURE----- --Sig_/0+fu2zz6_89SaRTEFZ_hgAl--