Re: [2.6 patch] i386: always use 4k stacks

Arjan van de Ven
2005-11-16T08:04:04Z

On Tue, 2005-11-15 at 16:50 -0800, Alex Davis wrote:
> Could someone either list or post a link to someplace that lists
> all the advantages of 4K stacks?

* less kernel memory (eg lowmem) used for a thread
- allows more threads on the same system (java!)
- increases performance in high-thread systems because more memory
is available for disk cache etc
* thread stacks are now order 0 not order 1
- order 0 is easy for the VM, order > 0 is harder (increasingly so
the higher the order; so the 16Kb/32Kb request is just really
wrong). For order > 0, fragmentation becomes an issue (just look
at the entire fragmentation debate from a few weeks ago how bad
a problem fragmentation can be). Thread stacks are just about the
last remaining "big" user of order > 0 allocations normally.
(eg excluding init/setup code)
- order 0 allocations come from a per cpu "quicklist" of pages,
while order>0 allocations need to go to a global allocator pool.
"global" means "cache line bounces" and "cpu scalability problem".
* less CPU cache footprint due to interrupt stacks
- interrupt stacks are per cpu now instead of borrowing the per
thread stack space; this both has less impact on the caches, and
has more cache hits; the per cpu stack will be in cache more than
the previously scattered bits and pieces
* more stack space is available for interrupts compared to 2.4 kernels
- in 2.4 kernels only 2Kb was available for interrupt context (to
keep 4K available for user context). With complex softirqs such as
PPP and firewall rules and nested interrupts this wasn't always
enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
2Kb extra available there compared to 2.4 and arguably some of that
extra is for interrupts.