[PATCH] introduce CONFIG_BUFFER_SIZE()
vda.linux at googlemail.com
Thu Aug 5 22:46:07 UTC 2010
On Thursday 05 August 2010 21:57, Alexander Shishkin wrote:
> > > Well, on-stack allocation is cheaper since it doesn't require any extra
> > > calls in userspace.
> > Yes. But this seems to be the only positive side.
> > Whereas negative sides are the following:
> > There are limits on how much you can allocate. Even on MMU machines
> > like x86 the limit is 8 mbytes (nscd had bugs where that was a problem);
> That's per-process and adjustable. And I can hardly think up a situation
> (apart from a bug), when busybox might get remotely close to that.
nscd author thought the same. Why use "boring" and "slow" malloc()
when we can be clever and use "fast" and "neat" alloca()?
Oh no, who could have thought "guest" group can have 500k+ members
and therefore its "struct group" is >8m? ...KABOOM...
> > Stack can grow, but it never shrinks; if you run something deeply
> It gets deallocated when busybox exits. And correct me if I'm wrong,
> but I think quite some of busybox applets are of get-in-quickly-do-your-
> business-and-leave persuasion, so that in most cases one shouldn't worry
> about busybox leaking stack.
Yes. But we do have a number of servers. We can't say
"heh, bbox server process ate a meg of stack? So what?"
malloc() works well for any scenario. What other deficiencies
malloc() has apart from small time penalty?
> > > In a situation with heavy memory pressure, you might
> > > well end up having malloc() returning NULL, which will lead to busybox
> > > exiting, whereas with onstack allocation you it will trigger OOM killer
> > > which is likely to kill something else.
> > And having a random other application killed is better because ... ?
> It's obviously badly written and needs fixing and it's standing in the way
> of me trying to do my stuff by means of busybox.
A RANDOM app is badly written because it was nuked by OOM killer?
How did you arrive to that conclusion?
More information about the busybox