Re: 2.6.6-rc3-mm2 (4KSTACK)
From: Helge Hafting
Date: Tue May 11 2004 - 03:46:15 EST
Bill Davidsen wrote:
Arjan van de Ven wrote:
It's probably a Bad Idea to push this to Linus before the vendors
significant market-impact issues (again - anybody other than NVidia
have gotten their stuff cleaned up...
Ok I don't want to start a flamewar but... Do we want to hold linux back
until all binary only module vendors have caught up ??
My questions is, hold it back from what? Having the 4k option is fine,
it's just eliminating the current default which I think is
undesirable. I tried 4k stack, I couldn't measure any improvement in
anything (as in no visible speedup or saving in memory).
The memory saving is usually modest: 4k per thread. It might make a
those with many thousands of threads. I believe this is unswappable
which is much more valuable than ordinary process memory.
More interesting is that it removes one way for fork() to fail. With 8k
the new process needs to allocate two consecutive pages for those 8k. That
might be impossible due to fragmentation, even if there are megabytes of
memory. Such a problem usually only shows up after a long time. Now we
only need to
allocate a single page, which always works as long as there is any free
memory at all.
For an embedded system, where space is tight and the code paths well
known, sure, but I haven't been able to find or generate any objective
improvement, other than some posts saying smaller is always better.
Nothing slows a system down like a crash, even if it isn't followed by
a restore from backup.
Consider the case when your server (web/mail/other) fails to fork, and then
you can't login because that requires fork() too. 4k stacks remove this
and is a stability improvement.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/