__uc_malloc

Bernhard Fischer rep.dot.nop at gmail.com
Mon Jun 9 11:18:25 UTC 2008


On Mon, Jun 09, 2008 at 12:55:13PM +0200, Bernd Schmidt wrote:
> Denys Vlasenko wrote:

>> This actually _improves_ our performance in near-OOM conditions.
>> How? Going back to crypt(). If we will go back and reinstate
>> static buffers there, busybox's data+bss size will jump from 8k
>> to 80k - tenfold increase. On NOMMU, if you have N running
>> busybox daemons, you already have additional N*72k bytes
>> allocated and sitting there, totally unused.
>
> Well, wasting memory at run-time is inherent in the design of busybox.  
> Have you considered that it might be busybox that is broken?

That's exactly the reason why we have the option to build individual
applets at the cost of some added complexity due to dynamic libraries
and a bit of disk-space. I think it would be better to try to use (or
add to libc, if really needed) _r functions in busybox to minimize the
bss impact.
I'm aware that there is no really cheap way out of this misery, but if
bss of libbusybox is still too big, then we could split it into separate
sub-libs for a given problem-domain. Just an idea..



More information about the uClibc mailing list