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

  • Next message: Andrew Morton: "timepegs updated"

    > 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 : Sat Mar 25 2000 - 08:56:51 EST