[Top] [All Lists]

Re: fc3 and stacks

To: Robin Humble <rjh@xxxxxxxxxxxxxxxx>
Subject: Re: fc3 and stacks
From: Eric Sandeen <sandeen@xxxxxxx>
Date: Mon, 14 Mar 2005 14:46:28 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20050314190915.GB9784@lemming.cita.utoronto.ca>
References: <20050310232036.GA19295@lemming.cita.utoronto.ca> <4234E903.8010309@thebarn.com> <4235D44F.1020902@tippett.com> <20050314190915.GB9784@lemming.cita.utoronto.ca>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Robin Humble wrote:

Some ways forward:
 - convince RedHat to put 8k stacks (or at least the option for it) and
   XFS into AS4.

FWIW, I try to steer the conversation away from "xfs is broken with 4k stacks" and towards "4k stacks don't work for some applications." :)

XFS can chew through stack a bit faster than some of the filesystems, to be sure. But I've always meant to try to put together some diabolical "supported" config on RHEL4 and file a bug - say nfs over deeply nested volume managers, or something like that.

 - try to make XFS play nicer with 4k stacks
 - run fc3. fc3 and AS4 are very similar (~ 50% of userland rpms are
   identical, the rest seem to be fairly minor variations), so if your
   vendor supports AS4 then it'll almost certainly run fine on fc3

but both fc3 and RHEL4 have 4k stacksm though...

- install AS4 but run a fc3 (recompiled for 8k stacks) kernel

...ah, yes.

- install AS4 but run a stock kernel.org (or XFS cvs) kernel

Seems like with RHEL3, stock kernel.org kernels don't play nicely. I hope this isn't the case with RHEL4, but I have not tested it.

But rebuilding the stock RHEL4 kernel, with tweaks to turn xfs back on, maybe update xfs, and re-enable 8k stacks should be possible, if not supported by RH. :) Or as suggested by Andi, just pick one of the arches that have larger stack space (x86_64) (hm, I should verify that that's still fine on RH kernels... maybe they made them 1k stacks) :)

The first 2 of these are hard, the last 2 are pretty easy but may not
help you from a vendor support point of view. We'll probably choose the
last option.
The middle option (fc3) is what you are doing now, so you can get some
idea of XFS stability with 4k stacks for your particular workload.

I wonder why RedHat was so keen to remove 8k as an option. Things would
be fairly simple if they hadn't done that.

I think there are some applications (java?) that can benefit from smaller stacks in terms of overal thread count & memory usage... but I don't know why they went so far as to actually remove the option.


<Prev in Thread] Current Thread [Next in Thread>