Cc: Arjan van de Ven <arjan@...>, Adrian Bunk <bunk@...>, Alan Cox <alan@...>, Shawn Bohrer <shawn.bohrer@...>, Ingo Molnar <mingo@...>, Andrew Morton <akpm@...>, Linux Kernel Mailing List <linux-kernel@...>, Thomas Gleixner <tglx@...>
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.
--
