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

[Arjan van de Ven]

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.




-
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/