Re: [2.6 patch] i386: always use 4k stacks

[Ray Lee]

(Man, I've been holding my tongue on this conversation for a while,
but it seems my better angels have deserted me.)

On 12/15/05, Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> Bugzilla link please.

No, that's not how failure engineering is done. A guy designing a
bridge doesn't cut all the supports back to the bare minimum just to
save money because his design says that the remaining metal should be
strong enough. If you can't prove it, and it's a safety issue
(continuing my analogy in the physical world), then you engineer for
failure. Can you handle all occurrences? No, a hurricane Katrina comes
along every once in a while. Can you weather more than you did before?
Yes. In the meantime, their are fewer poor sods falling off the bridge
that have to open a bugzilla report.

The world of software is no different. If someone wants to remove the
8k stacks option, they'd better prove that they're making my servers
more reliable. I've seen zero arguments for why 8k stacks is unviable.
(I've also wondered why we can't just have IRQ stacks plus 8k thread
stacks -- seemingly the best of both worlds) Instead, what I've seen
is that we have coders who don't like the idea of any non-order-zero
allocations taking place, because big systems running poorly coded
Java apps with massive threading can hit problems with allocations
from time to time.

The answer for that is the same answer the kernel community usually
gives about poorly designed userspace applications: rewrite them.

I'm quite open to being proved wrong. If someone has a counter case
they can toss forth, please do so. Systems taking lots of interrupts?
Then how about 8k + IRQ stacks? With a counterexample I'll gladly
concede that I'm an ignorant slut[*] -- excuse me, Saturday Night Live
flashbacks -- an ignorant git, and shut up. ([*] is only half right,
I'm not all that ignorant).

If someone doesn't show a counter case, then may I suggest people
consider the possibility that this is not proper engineering. Prove
it, or provide a safety blanket. But don't yank the blanket without
proving the lack of problem.

Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/