[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yw1xsl7p8qlh.fsf@thrashbarg.mansr.com>
Date: Sun, 15 Jul 2007 19:32:58 +0100
From: Måns Rullgård <mans@...sr.com>
To: linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
Arjan van de Ven <arjan@...radead.org> writes:
> On Sun, 2007-07-15 at 19:17 +0200, Bodo Eggert wrote:
>> Matt Mackall <mpm@...enic.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@...sr.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists