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

[Dave Jones <davej@redhat.com>]

On Fri, Dec 16, 2005 at 10:50:54PM +0100, Adrian Bunk wrote:
 > On Fri, Dec 16, 2005 at 04:28:15PM -0500, Mike Snitzer wrote:
 > >...
 > > Given Neil Brown's fix for the block layer these stack-heavy workloads
 > > that included DM in the call chain need to be revisited.  However, the
 > > savings associated with those particular fixes still may not leave
 > > sufficient breathing room.  The logic that all users must NOW provide
 > > workloads which undermine 4K stack viability otherwise the 8K option
 > > will be completely removed _seems_ quite irrational (even though we
 > > are _supposedly_ just talking about doing so in -mm).
 > > 
 > > All of us appreciate the desire to have Linux be more efficient and 4K
 > > stacks will get us that.  If it comes with the cost of instability
 > > under more exotic workloads then the bad outweighs the perceived good
 > > of imposed 4K stacks.  With RHEL4 it would seem we're past the point
 > > of no-return for supported 8K stacks.  I'm merely advocating upstream
 > > give users the 8K+IRQ stack _options_ and set the default to 4K.
 > 
 > My count of bug reports for problems with in-kernel code with 4k stacks 
 > after Neil's patch went into -mm is still at 0. That's amazing 
 > considering how many people have claimed in this thread how unstable
 > 4k stacks were...
 > 
 > Enabling 4k stacks unconditionally for all -mm users will give us a 
 > wider testing coverage and will tell us whether we have really fixed all 
 > bugs that become visible with 4k stacks or whether there are still bugs 
 > left.

As another anecdotal point, the number of oomkill/page alloc failure
related bugs that get filed against Fedora these days you can count
on one hand.  Before we switched over to 4K stacks, we were
getting regular reports from users having quite sane workloads on
capable machines getting jobs killed left and right.

Now the only cases we're seeing is usually loonies trying to
put silly amounts of RAM in 32bit systems, and the occasional
bug which turns out to be a slab leak or something similar.
(There's one oddball right now where someone sees his 5GB
 x86-64 run out of DMA zone, but that might 'go away' when
 we push out a kernel with the DMA32 zone).

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/