From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4455 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Removing sbrk and brk Date: Mon, 6 Jan 2014 17:40:36 -0500 Message-ID: <20140106224036.GC24286@brightrain.aerifal.cx> References: <20131221234041.GA13204@brightrain.aerifal.cx> <20131222184855.GS1685@port70.net> <20131223044609.GZ24286@brightrain.aerifal.cx> <20140102220302.GR24286@brightrain.aerifal.cx> <20140103173301.GU24286@brightrain.aerifal.cx> <20140103181906.GV24286@brightrain.aerifal.cx> <20140103190350.GW24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1389048050 13741 80.91.229.3 (6 Jan 2014 22:40:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 22:40:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4459-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 06 23:40:54 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 1W0Iqp-0007gw-Ud for gllmg-musl@plane.gmane.org; Mon, 06 Jan 2014 23:40:52 +0100 Original-Received: (qmail 7616 invoked by uid 550); 6 Jan 2014 22:40:50 -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 7604 invoked from network); 6 Jan 2014 22:40:49 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4455 Archived-At: On Mon, Jan 06, 2014 at 02:51:11PM +0000, Thorsten Glaser wrote: > Rich Felker aerifal.cx> writes: > > > > Overall my assessment is that omalloc is _simple_ (in some ways > > > simpler than musl's), but looks to have much worse fragmentation > > > properties, much worse performance properties (both syscall overhead > > > and locking come to mind), and no other clear advantages. > > I think the idea behind simplicity was ease of auditing, and the Indeed, this makes sense. > fragmentation properties are accepted because omalloc inserts > unmapped guard pages between allocations and randomises them > (via mmap) for proactive security reasons. This seems to be optional behavior; using guard pages with all allocations would blow up memory usage several thousand times and limit the number of allocations possible on 32-bit systems to well under one million -- yielding an unusable system. > But I guess it depends on whether you want to optimise for speed. > On the other hand, just the suggestion of reverting (in my eyes) > to the musl behaviour of having a heap that’s grown/shrunk dynamically > for smaller objects smells weird to me (with the BSD developer hat on). In what way? The basic dlmalloc design musl uses is basically known (albeit without any proof I'm aware of) to be the only efficient way to do malloc. Pretty much all "improvements" to it actually sacrifice O(1) operations or low fragmentation to buy performance improvements in certain cases deemed likely (and of course making the worst-case worse). > But I’m just a downstream of omalloc. I really suggest to talk to > Otto Moerbeek, who, in contrast to most OpenBSD developers, is > pleasant to talk with and approachable. Might be interesting, but pretty off-topic. Using the OpenBSD malloc in musl is not something that's really on the table. Rich