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 12:06 PM, Bodo Eggert wrote:
> > On Tue, 17 Jul 2007, Rene Herman wrote:
> >> On 07/17/2007 01:45 AM, Bodo Eggert wrote:

> >>> 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.
> 
> Firstly, it's not two times 4K but 4K + (4K + 4K) * NR_CPUS. Secondly, _you_ 
> are the one making claims -- specifically that !CONFIG_4KSTACKS is "safer", 
> happily ignoring the fact that generally speaking available process stack 
> can be _better_ with CONFIG_4KSTACKS

It can be better, but the worst case stays 4K + 4K - unless one CPU will 
walk over to the next and nicely ask for a cup of stack.

Therefore you can discuss 4K + 4K or 4K + 4K + 4K, or 4K + 4K * \inf. It 
won't change a thing:

1) It all can be reduced to 4K + 4K by asuming all IRQ happen on one CPU.
2) Even if the interrupts decide not to happen on one CPU, you still can't 
   fit that possible 5K into 4K.

Having a local stack per CPU helps locality, and it's gootd, but that's 
about it.

> and there seems to exist but _one_ 
> (één, ein, une) known situation where it's problematic.

One case is reason enough not to enable 4K-stacks per default, and this 
is a common server setup. "server" as in "I need a reliable system".

> Must there be none rather than one? In some senses maybe, if the problem is 
> more than bad, fixable code but I doubt you know this. CONFIG_4KSTACKS is 
> much better on the VM (and hence faster) and as such,

"Look how fast I crashed!" doesn't buy you anything. In order to finish 
first, you first got to finish.

> any user not using the 
> one nicely isolated and identified problem case benefits from it.

And they can turn it on.

> This means 
> it's either very close or already _at_ the point of being the best default 
> for the kernel. Changing options is for users with special needs, as you 
> believe you are.

If you designed a car, you would also go for breaks with a well-known 
problem just because they weight less and all that people not crossing 
mountains would be happy about the weight benefit - that is if they'd 
notice, wouldn't you?

Please post a list of things you have designed, so I can avoid them.

> I truly apologise for taking it into this direction but you're wearing me 
> down rapidly.

I put the facts onto the ground. If you're getting down, you may stumble 
on them. Beware

> Every single time you insert some uninformed crap comment that 
> shows that you both don't understand the issue and didn't understand what 
> the other person was saying and then after being made aware of such, ignore 
> that and follow up with the next uninformed crap comment.

So what did you say about the worst case stack size being bigger than 4K?
That's correct, you choose to put it aside as a minor use case. Yea, it's
just the combination you'd choose for a reliable server setup, the users
won't have a problem when their systems crash ...

Was your claim about each CPU having a separate stack helping your cause?
No, everybody can see it's not. That is, except for you, your CPU will
just borrow some, since their neighbours have some free stack.


But let's not stop here: You claimed: "Unshared interrupt 
stacks 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."

So you want to tell me I can't prove 8K stacks are safe - you are right.
But can you prove 4K stacks are safe? You can't either. But you want to be
able to prove it. I told you to stick to your words - go and prove 4K+4K
to be safe. What did you do? You chose to ignore that.

I bet you don't even consider proving 4K stacks to be correct, nor do you
know anyone who would try that in the near future. And besides that, you
know at least one case where your proof would fail. So why would you talk
about proofs? Do you think you can trick me into believing a crashing 
system would work more correctly than a non-crashing one, just by 
mentioning the possibility of having it easier to make a proof?


Besides that, I told you you can separate unshared interrupt stacks from 
4K stacks. And yet, you still argue as if 4K stacks are required for 
having a separate interrupt stack.


So who's ignoring facts, who is talking crap?

> That is, you seem 
> to care less about the issue then about the discussion and since for me it's 
> quite the other way around I'm leaving it at that.

I know very well you're going to turn linux into a bleeding edge system 
where you're supposed to get some bad surprises on an update, unless you 
happen not to hit the error case. That's not the way I'd like it to go.
You may use -mm, you'll get the 4K stacks per default, be happy wih them.

> RedHat is the one with the actual data available, and they've been enabling 
> 4KSTACKS for quite some time now (with some of their users apparently 
> unhappy about it but not many it would seem).

Would you use a distribution crashing on your servers? Or would you change
the distribution and spread the word not to use redhat?

-- 
"'Multiple exclamation marks,' he went on, shaking his head, 'are a 
sure sign of a diseased mind.'"
	-- Terry Pratchett in "Eric"
-
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/