From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4454 Path: news.gmane.org!not-for-mail From: Thorsten Glaser Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Mon, 6 Jan 2014 14:51:11 +0000 (UTC) Message-ID: 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 1389019905 26799 80.91.229.3 (6 Jan 2014 14:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 14:51:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4458-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 06 15:51:52 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 1W0BWw-0008Uk-D1 for gllmg-musl@plane.gmane.org; Mon, 06 Jan 2014 15:51:50 +0100 Original-Received: (qmail 11945 invoked by uid 550); 6 Jan 2014 14:51:49 -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 11937 invoked from network); 6 Jan 2014 14:51:48 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 94.198.62.204 (Mozilla/5.0 (X11; Linux 3.12-1-amd64 i686) KHTML/4.11.3 (like Gecko) Konqueror/4.11) Xref: news.gmane.org gmane.linux.lib.musl.general:4454 Archived-At: 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 fragmentation properties are accepted because omalloc inserts unmapped guard pages between allocations and randomises them (via mmap) for proactive security reasons. > tight packing of small allocations. It also provides greater > protection against corruption of the internal malloc structures, in Indeed. > the sense of allowing the program to keep going after overflows, but > less ability to catch overflows and less protection from corrupting > other application data, unless you add back overhead just for that > purpose. Such as the guard pages, yes. 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). 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. bye, //mirabilos