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

[Adrian Bunk]

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.

-mm kernels contain many experimental features, and "completely removed" 
isn't really true because we can expect that people running the 
experimental -mm kernels to know how to un-apply a patch.

> Mike

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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