Messages in this thread | | | Date | Fri, 23 Dec 2005 14:59:10 +0100 | From | Diego Calleja <> | Subject | Re: [2.6 patch] i386: always use 4k stacks |
| |
El Fri, 23 Dec 2005 11:12:38 +0100, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> escribió:
> + printk(KERN_WARNING, "Can't allocate new task structure" > +#ifndef CONFIG_4KSTACKS > + ". Maybe you could benefit from 4K stacks.\n" > +#endif > + "\
A sarcastic patch, nice. So, lets try to get something useful from this flamewar...sight.
The 4k patch is being proposed for -mm. Personally I'm _shocked_ that so many people is trying to avoid _testing_ (-mm is for testing, isn't it) this feature so hard. Which is surprising, since merging it into -mm may prove that they're right (people will report bugs caused by 4k stacks, etc). Maybe 8k groupies are not willing to be proved that they're right, or they're afraid of being proven that they're wrong? </sarcasm>
Now, seriously: I think that most of the 8k groupies don't like 4k not because it doesn't works in the common case, but because it could cause hangs that are not easy to reproduce (ie: they are paranoid). The combination of code paths is too big and complex. I can understand that.
What I don't know is why you think that 8k will be "safe". As far as I know, there're have been stacks overflows with 8KB stacks in the past (ie, "hangs that are not easy to reproduce") before the 4k stack patch was proposed, and the _one_ reason why now it's very safe to run with 8k stacks is because the 4k stack patch has forced people to do stack diets, not because 8k is the best option.
We have *NO* *WAY* of proving that it's safe to run either 4k or 8k stacks. Face it. And since such bugs can exist no matter what stack size you use, the best option (IMO) is to choose the option that will allow us to hit those bugs _faster_, ie: 4k stacks. From a engineering point of view, I can't understand why hiding the problem is better than choosing the path that will allow to hit and fix those bugs faster. It remembers me of "security through obscurity". What we will do when we have too may overflows with 8K? 16K stacks? Oh, let me guess: "we'll fix it"?. Well, and why can't we fix 4k stacks???
Now, the code is easy to maintain and some people depends on 8k stacks, as akpm pointed out in http://lkml.org/lkml/2005/12/15/336 This patch (http://lkml.org/lkml/2005/12/16/89) stolen from^W^Winspired by Adrian Bunk defaults to 4k, makes the 8k people happy and it should make akpm happy too.
Can someone tell me a reason why all this stupid flamewar can't be solved with that patch? - 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/
| |