On Sun, Apr 20, 2008 at 02:27:14PM +0200, Andi Kleen wrote:Clearly if I have the choice between a kernel which can run 50k threads and a kernel which does not crash under me during an I/O error, I choose the later! I don't even imagine what purpose 50k kernel threads may serve. I certainly can understand that reducing memory footprint is useful, but if we want wider testing of 4k stacks, considering they may fail in error path in complex I/O environment, it's not likely during -rc kernels that we'll detect problems, and if we push them down the throat of users in a stable release, of course they will thank us very much for crashing their NFS servers in production during peak hours. I have nothing against changing the default setting to 4k provided that it is easy to get back to the save setting (ie changing a config option, or better, a cmdline parameter). I just don't agree with the idea of forcing users to swim in the sh*t, it only brings bad reputation to Linux. What would really help would be to have 8k stacks with the lower page causing a fault and print a stack trace upon first access. That way, the safe setting would still report us useful information without putting users into trouble. Willy --
| Joe Perches | [PATCH 143/148] include/asm-x86/vm86.h: checkpatch cleanups - formatting only |
| Linus Torvalds | Re: Back to the future. |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
