From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4456 Path: news.gmane.org!not-for-mail From: Thorsten Glaser Newsgroups: gmane.linux.lib.musl.general Subject: Re: Removing sbrk and brk Date: Tue, 7 Jan 2014 09:43:26 +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> <20140106224036.GC24286@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 1389087842 21895 80.91.229.3 (7 Jan 2014 09:44:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 09:44:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4460-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 07 10:44:10 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 1W0TCg-0003p5-J6 for gllmg-musl@plane.gmane.org; Tue, 07 Jan 2014 10:44:06 +0100 Original-Received: (qmail 30650 invoked by uid 550); 7 Jan 2014 09:44:05 -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 30642 invoked from network); 7 Jan 2014 09:44:04 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 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:4456 Archived-At: Rich Felker aerifal.cx> writes: > This seems to be optional behavior; using guard pages with all > allocations would blow up memory usage several thousand times and No, they aren’t accessible, so the kernel (should) never maps them to any real RAM. > limit the number of allocations possible on 32-bit systems to well > under one million -- yielding an unusable system. FSVO unusable. The default datasize ulimit on OpenBSD/i386 2.x/3.x was 128 MiB, with the maximum having been 1 GiB (now 1.5 GiB, I believ), anyway, so there is enough space for that. (In general, they heavily use this – randomisation and guard pages.) But this is getting even more OT. > > 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 Mmhm. I must admit I had hoped to be able to pick some fruit from that since you do bring up things I’d not have thought of. But np. > but pretty off-topic. Using the OpenBSD malloc > in musl is not something that's really on the table. OK. I was just suggesting this in case it would have been something you could have / wanted to use, and had not thought of already. That’s it from me on the malloc thread. bye, //mirabilos