centos, oracle and redflag tend to follow the RHEL/fedora settings.
To be honest, at this point we're at a situation where
* Several very popular distributions have this enabled for 5+ years,
apparently without any real issues (otherwise the enterprise releases
would have turned this off)
* The early "hot known issues" have been resolved afaik, things like
block device stacking, and symlink recursion lookups are either no longer
recursive, or a lot less recursive than they used to be.
There are clear benefits to 4K stacks (no need to reiterate the flamewar,
but worth mentioning)
* Less memory consumption in the lowmem zone (critical for enterprise use,
also good for general performance)
* Kernel stacks at 8K are one of the most prominent order-1 allocations in the
kernel; again with big-memory systems the fragmentation of the lowmem zone
is a problem (and the distros that ship 4K stacks went there because of customer
complaints)
On the flipside the arguments tend to be
1) certain stackings of components still runs the risk of overflowing
2) I want to run ndiswrapper
3) general, unspecified uneasyness.
For 1), we need to know which they are, and then solve them, because even on x86-64 with 8k stacks
they can be a problem (just because the stack frames are bigger, although not quite double, there).
I've not seen any recent reports, I'll try to extend the kerneloops.org client to collect the
"stack is getting low" warning to be able to see how much this really happens.
for 2), the real answer there is "ndiswrapper needs 12kb not 8kb"
for 3), this is hard to deal with but also generally unfounded... you can use this argument against any change in the kernel.
--
