begin  quoting Tracy R Reed as of Fri, Oct 12, 2007 at 01:50:05PM -0700:
> Mike Marion wrote:
> >Quoting Andrew Lentvorski <[EMAIL PROTECTED]>:
> >>B) Linux is just a touch unstable when pushed hard
> 
> We've heard this for years from people who can't point to any reason 
> (line of code) why.

Wow. I'll have to file that as a response to the next bug report I get.
"Did not specify line of code causing application to crash and corrupt
all data files. Bug denied."

(Do I need to mark that as humor?)

Instability problems are annoying, but waving your hands doesn't make
it more stable.  Or if it does, I've been doing it ALL wrong.

> >We've found that it handles the cpu load just fine, it's when it's run  
> >into OOM situations too far and too fast that it falls over sometimes.  
> 
> You can't go too far into "OOM". When you are out of memory you are out. 
> What do you expect it to do when OOM?

Complain. Slow down. Stay running long enough for me to identify and
kill the offending process.

>                                       It must be something which does 
> not require the allocation of any more memory.

Well, if all processes have equal access to all memory, sure. But it's a
good idea to hold some memory in reserve for key processes.

>                                                There is no perfect 
> solution.

That's a bad excuse for a poor solution.

Now, I'd agree that there's no *optimal* solution for all desired
behavior (stay up, stay running, keep the offending process around
for forensic investigation, kill the offending process so let the
system keep running...), but at a minimum, the system should degrade
gracefully.

Falling over isn't graceful.

>           The current policy is to kill off the process which most 
> recently tried to malloc as this is probably the one likely to be using 
> up most of the memory.

Um.... no.

Having a root shell up when something goes haywire, and then having that
root shell killed when you run, say,  ps... that's a pessimal solution.

[snip]
> >>If you do Solaris x86, suddenly these two things go away.
> 
> I find that hard to believe. When swapping the disk is going to be the 
> bottleneck regardless of OS.

Swapping algorithms have some effect, surely. But yah, you hit swap
hard enough, and anything will get sluggish.

-- 
Slow is not the same thing as instable.
Stewart Stremler


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to