Date: Tue, 7 Jan 2014 11:06:27 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: Removing sbrk and brk On Tue, Jan 07, 2014 at 09:43:26AM +0000, Thorsten Glaser wrote: > Rich Felker <dalias <at> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.