CONFIG_4KSTACKS

[Patrick Doyle]

Does anybody know if there is a specific reason that the Fedora
kernels (i686, FC6, anyway) are compiled with with CONFIG_4KSTACKS?
Is there any reason _not_ to enable larger interrupt stacks?

I realize that this is more of a development list question, than a
"general users" question, but I figured I'd start here, since I'm
subscribed to this list.

--wpd

[Robert Locke]

On Sat, 2007-03-03 at 15:51 -0500, Patrick Doyle wrote:
> Does anybody know if there is a specific reason that the Fedora
> kernels (i686, FC6, anyway) are compiled with with CONFIG_4KSTACKS?
> Is there any reason _not_ to enable larger interrupt stacks?
>
> I realize that this is more of a development list question, than a
> "general users" question, but I figured I'd start here, since I'm
> subscribed to this list.
>
> --wpd

Because the upstream kernel decision was to use 4KSTACKS.  You need to
take that up with Linus.... :-)  Feel free to search the lkml archives,
for a technical discussion on the merits of 4K vs. larger, but the short
answer is that those technical folks like 4K better (I seem to recall
something to the effect of big stack equals sloppy coding)....

The usual "reason" people Bring this up is because they are trying to
run a Windows driver.  The reality of that situation is that while the
8K Stack code handled most of them, technically, Windows expects a 12K
stack which might be some of the "problems" people are having with those
as it is.  The "real solution" here is for the ndiswrapper project to
modify their code to manage their own stack and not rely on the kernel
stack.  This has been flamed to death over the last few years, so it's
not like they didn't know this was coming.....

My personal solution was to ensure that I purchased equipment that had
native driver support (though admittedly this userspace daemon thing was
obviously a mistake, since they are re-writing it...).  This has the
effect, by the way, of showing purchasing following a Linux need and
maybe the hardware vendors will begin to see more of us and hence we
might receive a little more support/respect.

--Rob

[James Wilkinson]

Robert Locke wrote:
> Because the upstream kernel decision was to use 4KSTACKS.  You need to
> take that up with Linus.... :-)  Feel free to search the lkml archives,
> for a technical discussion on the merits of 4K vs. larger, but the short
> answer is that those technical folks like 4K better (I seem to recall
> something to the effect of big stack equals sloppy coding)....

On PowerPC, x86, and x86_64, physical memory (and swap-space) is divided
into 4K pages[1][2], and allocated and managed as 4K pages.

For normal programs, the kernel and the Memory Management Unit(s) in the
processor(s) can concatenate these pages in whatever order necessary so
it "looks" to the program as though it has a seamless allocation of
memory.

This doesn't work for the kernel. If the kernel wants 8K of memory in
one "lump", it needs to find two free 4K pages that are together in
memory.

This turns out to be a problem -- after the computer has been running
for a while, there may not be any adjacent pages available. Each process
needs its own stack, so this can mean that it's not possible to start
any more processes. Many Unix programs rely on being able to start new
processes easily, so this can be a big problem.

http://lwn.net/Articles/84583/
http://lwn.net/Articles/150580/
http://lwn.net/Articles/160138/

Hope this helps,

James.
[1] Usually -- occasionally 2MB, 4MB or 1 GB pages are used...
[2] Other architectures may have different size stacks -- I believe
Alpha has 8K, and the old VAX had 512 bytes.