From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4457 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Removing sbrk and brk Date: Tue, 7 Jan 2014 11:06:27 -0500 Message-ID: <20140107160627.GD24286@brightrain.aerifal.cx> References: <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 1389110796 6808 80.91.229.3 (7 Jan 2014 16:06:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 16:06:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4461-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 07 17:06:43 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 1W0ZAw-0004We-89 for gllmg-musl@plane.gmane.org; Tue, 07 Jan 2014 17:06:42 +0100 Original-Received: (qmail 22014 invoked by uid 550); 7 Jan 2014 16:06:41 -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 21999 invoked from network); 7 Jan 2014 16:06:40 -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:4457 Archived-At: On Tue, Jan 07, 2014 at 09:43:26AM +0000, Thorsten Glaser wrote: > 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. The point is that even a 1-byte allocation (in fairness, that would be rounded up to at least 16 bytes) ends up consuming a whole page and thus 4k of storage, plus another 4k of virtual address space for the guard page. On MIPS it may be even worse (16k pages are required on some hardwasre). > > 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 If the datasize ulimit was 128M, that translates (via the above waste of a whole page per allocation) into an actual allocation limit that may be at low as 512k (if all allocations are small). That's getting out of the "FSVO" range and into the "plain unusable" range. For more typical allocation sizes, the available total might be more like 5-20M. Rich