Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

[Arjan van de Ven <arjan@infradead.org>]

On Sun, 2007-07-15 at 19:17 +0200, Bodo Eggert wrote:
> Matt Mackall <mpm@selenic.com> wrote:
> > On Fri, Jul 13, 2007 at 03:20:54PM +0200, Rene Herman wrote:
> 
> >> As far as I'm aware, the actual reason for 4K stacks is that after the
> >> system has been up and running for some time getting "1 physically
> >> contiguous pages" becomes significantly easier than 2 which wouldn't be
> >> arbitrary.
> > 
> > If there are exactly two free pages in the system, the odds of them
> > being buddies (ie adjacent AND properly aligned) is quite small. The
> > available page pool has to grow quite a bit before the availability of
> > order-1 page pairs approaches 100%.
> 
> If there are exactly two free pages in a system, the odds of starting any
> program are not very good. You'll have to swap, and if you do, you can swap
> two more pages in order to free enough RAM for the stack.


even if you have several thousand pages the odds aren't good; or rather,
they start out reasonably ok until something starts eating very
deliberately at the 8k pages pool, for example the new app creating
about 10 threads....

The 4K issue is "tricky", only a few selected workload/compiler combos
seem to hit the dirt, yet distros like Fedora and RHEL use 4K stacks
since forever, and if it gave massive problems they wouldn't do that.
On the upside, especially on very-threaded workloads, it helps
reliability and the VM a lot...


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