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 that have
significant market-impact issues (again - anybody other than NVidia here?)
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 difference for
those with many thousands of threads. I believe this is unswappable memory,
which is much more valuable than ordinary process memory.

More interesting is that it removes one way for fork() to fail. With 8k stacks,
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 free
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 scenario,
and is a stability improvement.

Helge Hafting
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at