Re: [RFC] One solution for the oom/overcommit debate

From: Steffen Ullrich (coyote.frank@gmx.net)
Date: Sat Mar 25 2000 - 08:40:42 EST


> 2. Per-task priorities (not in the "nice" priority sense though)
> Some tasks should never be signalled, like the X server or a login
> shell. Other tasks should be the first to go against the wall and
> face the firing squad. If the OOM killer patch is to use this new
> task priority, I need to add an int to task_struct and a system
> call to allow the daemon to set the priority. This places policy
> in user-space, while preventing system crashes when OOM.

A few years ago (after getting OOM problems on Digital UNIX where it killed
the inetd process and locked me out remotly) I had a similar idea (but it's still
only an idea, nothing implemented):
- Every process has an "importance" value.
- the first process (e.g. init) starts with a high importance value
- each child process gets smaller importance than the parent process on fork()
- root processes might increase their importance value, all other processes
  might only decrease the importance (similar to scheduling policy). maybe
  a root process should be able to increase the importance of other processes
  too.
- If the system gets into a OOM situation it starts killing the least important
  processes (e.g. the once with the smallest importance value) until it gets
  out of the OOM situation

I think the implementation of the whole stuff shouldn't be that hard (but
I never did any kernel hacking, so don't count on me). I also think that no
programs have to be changed to get the desired behavior: xterm will w/o changes
have less priority than the X server (because it's a child of X), user programs
started from the xterm shell will have even smaller priority. The only user space
thing needed would be a program similar to nice so that I could for instance
start a daemon with a higher importance from within an unimportant user xterm.

Maybe I'm complete wrong, but in my simple mind the whole idea sounds simple
but nearly perfect.

-
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.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:15 EST