lkml.org 
[lkml]   [1998]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A true story of a crash.
Matt Agler wrote:

> On Sat, 15 Aug 1998 linker@z.ml.org wrote:
> >
> > You could also check what processes have network sockets open.
> >
> > You done want to kill:
> [snip]
> > You sigterm, and log:
> [cut]
> > Then, if you are still tight you sigterm:
> [more cut]
> > Then you kill the above.
> >
> > Then you wait a userdefinable time out, and either reboot the computer or
> > kil everything except init and signal init to resart.
> >
>
> Hmm, doesn't that seem a bit complicated? The whole problem here is that
> the computer really has no knowledge of what should and should not be
> killed. You're just making elaborate guesses. The kernel can't read the
> users mind to find out which process is least important. There's no
> static mapping between size, priority, resource use, etc. to importance.
>
> It would be better and simpler to let the user or admin decide what to
> kill. Instead of killing a process, we should put it to sleep.
>
> If the machine has overextended itself, we're probably swapping like mad
> already. It's hammered. We're not getting anything done. We don't need
> efficiency anymore. We want recovery without loosing in-process work.
>
> For example, let's put each process, that asks for a page that we can't
> give, to sleep (from do_no_page?). This would be a special sleep in that
> it doesn't wakeup until we return to a certain threshold of free memory.
> What would happen is that it's pages would age and get thrown out. Other
> processes would complete. The load would be reduced until the machine was
> recoverable.
>
> root could login and fix the problem, add swap, kill stuff, whatever.
> Voila, the kernel didn't have to read the users mind and it stayed
> responsive.
>
> Admittedly, root would need to allocate memory and so any root processes
> should probably be exempt. If the box was administered right, I think
> this would be a workable scheme. ext2fs does a similar thing with regards
> to reserving space for root also, so there's a precident here I think.
>
> -Matt
>

This seems both awkward and ill-concieved. We want the computer to stay up. If
processes start falling asleep for no apparent reason, it it as if the machine
was locked up anyway. Also, root would need some way to know (from halfway
across the world) that this problem existed, and be able to fix it with ease.
This is not something that can be guaranteed. The kernel needs to be able to
make its own relatively inteligent decisions for how to deal with OOM.

It seems that a set of default rules that produce correct behavior 98% of the
time is far better than a guaranteed lockup, and if the admin needs to ensure
that a particular process does not get killed then a small program, executable
only by root, should be able to set the "death priority" of a process tree
beginning with the command-line specified. The Death Priority could be a way of
ranking programs by their relative necessity for correct operation of the
system. Everything would default to zero, and to be killed, you must have the
highest death priority and not be root, or els the highest death priority.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site