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

Måns Rullgård
2007-07-15T18:33:39Z

Arjan van de Ven <arjan@infradead.org> writes:

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

I guess no Fedora users run md+lvm+xfs then. That combination has
quite reliably crashed any 4k-stack kernel I've ever cared to try.

--
Måns Rullgård
mans@mansr.com