On Sunday 20 April 2008 08:27:14 Andi Kleen wrote:Andi, you're the only one I've seen seriously pounding the "50k threads" thing - I don't think anyone is really fooled by the straw-man, so I'd suggest you drop it. The real issue is that you think (and are correct in thinking) that people are idiots. Yes, there will be breakages if the default is changed to 4k stacks - but if people are running new kernels on boxes that'll hit stack use problems (that *AREN'T* related to ndiswrapper) and haven't made sure that they've configured the kernel properly, then they deserve the outcome. It isn't the job of the Linux Kernel to protect the incompetent - nor is it the job of linux kernel developers to do such. If people are doing a "zcat /proc/kconfig.gz > .config && make oldconfig" (or similar) the problem shouldn't even appear, really. They'll get whatever setting was in their old config for the stack size. And until the problems with deep-stack setups - like nfs+xfs+raid - get resolved I'd think that the option to configure the stack size would remain. Since the second-most-common reason for stack overages is ndiswrapper... Well, with there being so much more hardware now supported directly by the linux kernel... I'm stunned every time someone tells me "I can't run Linux on my laptop, there is hardware that isn't supported without me having to get ndiswrapper". The last time someone said that to me I pointed to the fact that their hardware is supported by the latest kernel and even offered to build&install it for them. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. --
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Rafael J. Wysocki | Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4d... |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
