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