|
Message-ID: <20140329180229.GL8221@example.net> Date: Sat, 29 Mar 2014 18:02:29 +0000 From: u-igbb@...ey.se To: Rich Felker <dalias@...ifal.cx> Cc: musl@...ts.openwall.com Subject: Re: malloc not behaving well when brk space is limited? On Sat, Mar 29, 2014 at 01:22:12PM -0400, Rich Felker wrote: > On Sat, Mar 29, 2014 at 07:15:02PM +0200, Timo Teras wrote: > > musl does not support external malloc. musl internal calls to > > malloc() are not overridable. Ok. > > I think you need to fix kernel. Rewrite allocator in musl. Or add the Too bad I can not choose the kernel on all the computers where I want my applications to run. To the contrary I am building as portable applications as possible. Hardly this situation is out of scope of musl (?) > > fallback code to mmap - but dalias said it's "hard". Perhaps still > > should be still reconsidered. > > Unfortunately the approach I want to use with mmap seems to be what > glibc uses for its thread-local arenas, and it performs something like > 2 to 10 times worse than brk... So unless we can solve that, I don't > think it's a good option. It could be a fallback, but I still don't > want PIE binaries running that much slower just because the kernel is > doing something wacky and wrong. It is a _lot_ better to run an order of magnitude slower than to fail totally, isn't it? If you have any code doing mmap-fallback, I would be willing to test it and hopefully use. > We need a good solution for this problem but I don't have one yet. This looks like a showstopper. The applications do not work properly as-is and replacing malloc or adding mmap support from scratch by myself is a threshold too high, given the time constraints. :( In other words, a bad solution would be much better than no solution. Otherwise my impression from musl until now is excellent. Thanks for your work on it. Regards, Rune
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.