[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140107160627.GD24286@brightrain.aerifal.cx>
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.
