On Monday 21 April 2008 03:51:02 Andi Kleen wrote:My point was that people might try to make such a system work on a 32bit system and fail. The fact that the limit does exist and changing the stack size doesn't really help things is a key there. My point is that you can get a few more threads out of a machine with 4K stacks, even on 32bit. Sure, the difference is basically negligible, but it does happen. That extra available space may be the difference between a poorly coded program triggering random crashes (and the OOM killer) and the system surviving it. While it's true that I feel that the job of the kernel isn't to protect the incompetent, it should protect the competent admins from the incompetent developers (and middle management). True. But having that tiny bit of extra memory might be the difference between a crash and a somewhat memory starved but surviving system. I didn't say otherwise. I was pointing out that 50K threads isn't out of the question when looking at the workload provided (and ignoring all other memory concerns. However, I had hoped I wouldn't have to spell out the stuff I've had to point out in this mail. Yes, I know you didn't come up with it. But in seeing the original commit-log for it, I'm thinking that the '50K' number was initially meant as either a small joke or a dream of a maximum. Remember, you're talking about people that write the code in Java. It's going to spawn all kinds of threads anyway. I, personally, would write the code in a language giving me better control over the available resources. However, I'm not employed by any major company because I will almost always refuse to work on a project if it's being done in an inefficient manner. In that case I agree. It is very inefficient to do things that way. There was nothing else running on the machine and it was reporting lowmem free in the logs, just none "usable". Since the two biggest hogs on that box are Apache2 and MySQL - and since repairing the Apache2 config damage has halted further OOM's on that machine, I'm pretty much certain that it was Apache2 at fault, though since there were reports of free lowmem, I'm pretty certain it was a combination of fragmentation and Apache2. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. --
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 010/196] Chinese: add translation of Codingstyle |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 24/37] dccp: Processing Confirm options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| david | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
