[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <loom.20140107T104008-769@post.gmane.org>
Date: Tue, 7 Jan 2014 09:43:26 +0000 (UTC)
From: Thorsten Glaser <t.glaser@...ent.de>
To: musl@...ts.openwall.com
Subject: Re: Removing sbrk and brk
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.
> 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
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.
