> >
> > Also in the implementation I don't see any way 4Kb stacks could show up
> > in any benchmarks as negative; there are only 4 or 5 extra instructions
> > in any path, and afaics no cache downsides (in fact the same irq stack
> > memory is now reused for irqs instead of threadstack-du-jour, so less
> > footprint/hotter caches)
>
> The only downside is the potential crashes due to overflowing the stack,
> I'm not worried about 4kb stacks performing worse.
>
First of all the 8Kb->4Kb change sounds like a big change, but 4Kb
really is 4Kb+4Kb (eg interrupt stacks). So the net reduction in
available stack for user context is a lot less (IRQ context need at
least 2Kb given that this is reentrant code wrt softirq processing),
probably in the order of 2Kb (compared to 8Kb 2.6 kernels) to 500 bytes
compared to 2.4 kernels (in 2.4 you lost 1.5 to the task struct on the
stack).
The experience with Fedora so far is exceptionally good; in early 2.6
there were some reports with XFS stacked on top of DM, but since then
XFS has gone on a stack diet... also the -mm patches to do non-recursive
IO submission will bury this (mostly theoretical) monster for good.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]