Messages in this thread | | | Date | Sat, 25 Mar 2000 14:40:42 +0100 | From | Steffen Ullrich <> | Subject | Re: [RFC] One solution for the oom/overcommit debate |
| |
> 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/
| |