In a series of 5 patches, Jesper Juhl propsed moving 4K stacks from a debug feature to a non-debug feature, defaulting it to be enabled in the -mm tree. He referred back to a lengthy earlier discussion in which he had proposed making 4K stacks the default in the mainline kernel, then added:
"Based on the comments in that thread I conclude that 4KSTACKS are not really considered a debug-only feature any longer, but the time is not right (yet) to make them the default - and it's certainly not yet the time to get rid of 8K stacks."
"In that thread I promised to provide some patches that would lift 4KSTACKS out of debug-only feature status, which is what the first two patches in this series do. I also said I would provide a patch to make 4KSTACKS 'default y' to get more testing, but restrict that patch to -mm - that's the fifth patch in this series. Patches 3 & 4 in this series move the config option out of the Kernel hacking menu and into Processor types and features".
From: Jesper Juhl [email blocked] Subject: [PATCH 0/5] 4KSTACKS no longer a debug feature and doesn't belong in "Kernel hacking". Date: Sun, 12 Aug 2007 22:50:58 +0200 Hi, The short story: This is a series of 5 patches to a) lift 4KSTACKS from a debug feature to a non-debug feature and b) move it out of the Kernel hacking menu and into the Processor types and features menu and c) make it 'default y', but only for -mm. Some more explanation is probably needed, so here's the longer story: About a month back I posted a RFC patch with the subject "[PATCH][RFC] 4K stacks default, not a debug thing any more...?" to find out if I was right in assuming that 4K stacks were no longer considered a debug only feature and whether or not it would be sensible to make them default. You can find the head of the thread (100+ mesages) in the lkml.org archives here: http://lkml.org/lkml/2007/7/11/294 . Based on the comments in that thread I conclude that 4KSTACKS are not really considered a debug-only feature any longer, but the time is not right (yet) to make them the default - and it's certainly not yet the time to get rid of 8K stacks. In that thread I promised to provide some patches that would lift 4KSTACKS out of debug-only feature status, which is what the first two patches in this series do. I also said I would provide a patch to make 4KSTACKS 'default y' to get more testing, but restrict that patch to -mm - that's the fifth patch in this series. Patches 3 & 4 in this series move the config option out of the Kernel hacking menu and into Processor types and features - this makes sense once it is no longer a debug feature and the location is in line with m68knommu (which is the only arch with this config symbol in addition to i386 & sh) which already place that symbol there. Now for a bit on the actual patches. These are the patches in this series : [PATCH 1/5] 4KSTACKS, remove DEBUG_KERNEL dependency for i386 [PATCH 2/5] 4KSTACKS, remove DEBUG_KERNEL dependency for sh [PATCH 3/5] 4KSTACKS, move out of Kernel hacking menu (i386) [PATCH 4/5] 4KSTACKS, move out of Kernel hacking menu (sh) [PATCH 5/5] 4KSTACKS, make 'default y', -mm patch only. Andrew; as i386 & -mm maintainer I'm sending you patches 1, 3 & 5 - patches 2 & 4 for Super-H I would like a maintainer ACK on before they go further, so I'm not Cc'ing you on those (they are on LKML if you want them anyway). Paul; in the thread I mention above I was focusing 100% on i386. I don't really know the status of 4KSTACKS on sh, so I'd like your input. I'm adding a few people from the previous thread to Cc, but far from everyone as then the Cc list would become too big. For the patches themselves I'm just sending them to LKML, Andrew & Paul, so pick them up on LKML please (sending as replies to this mail). Kind regards, Jesper Juhl
I'm all for it!
I'm definitely in favor of making 4K kernel stack the default. I've been running it for at least a year and no problems whatsoever. It makes life for kernel so much easier (allocating only one page, not two, every time you make new process) it's a must.
Some of you might remember that long ago kernel stack *was* 4K, but only dirty drivers forced it to be bigger and harder to allocate. Time to end that.
--
Maverick
www.linuxinsight.com
But wasn't the kernel stacks
But wasn't the kernel stacks also seperate for each handler back then? AFAIK, all handlers and bottom halves share the same stack now. I'm pretty sure that was the reason to make it bigger.
If the size it's a problem probably depends on the amount of drivers that is active.
Kernel threads acting on behalf of a process uses the process' stack.
What is the difference
What is the difference between stack sizes? How does it affect debugging?
The difference between 8K
The difference between 8K and 4K is 4K. What was your question again?
He's asking about the
He's asking about the consequences of using a 4K stack instead of an 8K stack.
4K stacks
There's a strong desire to move to 4k stacks, since they're dramatically easier for the kernel to allocate. With an 8k stack, the kernel has to find two consecutive pages of free memory, a so-called "order-1" allocation, which can be difficult on a long-running system with a fragmented memory space. With a 4k stack, the kernel merely has to find a free page.
Note that the free pages need to be physically contiguous, which is what makes this more challenging. In user space, pages can look contiguous but actually not be, due to virtual memory. The virtual addresses for two pages could be contiguous, while the physical pages are quite distant. The kernel, however, deals with physical addresses.
LWN had a good writeup on this a few years ago.
--
Program Intellivision and play Space Patrol!
Reiser4?
Does it work well with Reiser4 nowadays?
I'm free hacker.
There are only 2 good options to decide the best opportunity for any case.
If there are intensive I/O operations (e.g. disk transfers, internetworking transfers, ...) then they have intensive kernel's multithreaded operations and the 4 KiB kstack could be tiny to do some crash.
The limits of our problems are:
Anonymous Free Hacker ;)
Gibberish for you ;)
For the first option 1), the kstacks of size K 4KiB-kpages can be contiguous to be compacted if we want it.
But for the second option 2), the kstacks of size K 4KiB-pages are contiguous in K+1 kpages instead of K kpages where there is one kpage hole per kstack for the detecting of overflow of kstack using the interrupt handler (handling the missing page) of the kernel.
K = 1 .. infinite.
Brief summary:
Anonymous Free Hacker ;)
Gibberish for you ;) (corrected)
Ki for i-th kstack instead of K
Ki = 1 .. infinite
i = 1 .. infinite
Each i-th kstack has Ki 4KiB-kpages.
It's valid for all the architectures except that 8-KiB pagers like Alpha 21064, .. 21364.
Anonymous Free Hacker ;)