Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

[Bodo Eggert <7eggert@gmx.de>]

On Tue, 17 Jul 2007, Rene Herman wrote:
> On 07/17/2007 01:45 AM, Bodo Eggert wrote:
> > On Tue, 17 Jul 2007, Rene Herman wrote:
> >> On 07/17/2007 12:37 AM, Ray Lee wrote:

> >>> If at some point one of the pro-4k stacks crowd can prove that all 
> >>> code paths are safe
> >> I'll do that the minute you prove the current shared 8K stacks are
> >> safe. Do we have a deal?
> > 
> > You claim 4k+4k is safe, therefore 8k must be safe, too.
> 
> No, I most certainly do not. I claim proving that 4K and seperate (per cpu) 
> interrupt stacks are safe are exactly the same as proving unshared 8K stacks 
> are safe. That is, you don't, no such proof exists other than in the eating 
> of the pudding.

And yet you have a more strict claim than I do. If you are right, I'll be
right, too, because two times less-than-4K is less tham 8K. If I'm wrong
and 8K is not enough, you must be wrong, too, because you can impossibly
fit more than 8K into 4K+4K. That's the law of mathematics.

> Ray (and you) in considering !CONFIG_4KSTACKS to be "safer" 
> than CONFIG_4KSTACKS suggest that _inevitably_ CONFIG_4KSTACKS would leave 
> you with less available stack and I pointed out this isn't be the case.

Why do you insist on 4Kstacks being good as long as there is _one_ usevase 
not crashing the kernel? _All_ usecases have to be safe!

> And in fact, I shouldn't have said "exactly" the same. Unshared interrupt 
> stacks

, which are a completely different thing which was bundled to 4K-stacks
  because you need more than 4K,

> make for more determistisc behaviour, so you'd have a harder time 
> proven anything to some set limit of uncertainty with the shared 8K stacks 
> than with the unshared 4K stacks.

I don't want my stack to overflow in order to be theoretically able to
prove it does not overflow. I'd rather go for 8K+4K-stacks, and if _you_
have done the proof _you_ wanted to make, we can talk again about
4K-stacks. Then I'll just add up the maximum stack usages and have the
proof that 8K stacks are safe.

> > But if 8k is safe, this does not yet prove that you can store 5k+3k in
> > 4k+4k.
> 
> I really have not made any claim of the kind. The argument is that with 
> CONFIG_4KSTACKS, availeble stack space isn't inevitably less at any point in 
> time.

I claim, you can store 5k + 3k on the 8k stack, where 5k is something like
the current worst case for non-interrupt stack and 3k is plenty for
interrupts. Thousands of stable systems with 8K stacks support my claim.

You claimed with 4k + 4k, there is not less available stack space.
(At least for usecases you are interested in, but I'll asume you don't 
 want other usecases to crash.)

If you were right, I'd have enough space on 4k + 4k to store that 5k.
Obviously, thousands of systems disagree by crashing with 4K-stacks.
That's most simple logic.

Off cause I may be wrong and the kernels don't crash because of 4K stacks, 
but because of bad karma ... But even then, you'd first have to get rid of
that bad karma before defaulting to 4K stacks.

-- 
Top 100 things you don't want the sysadmin to say:
41. OH, SH*T! (as they scrabble at the keyboard for ^c).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/