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.