[RFC] One solution for the oom/overcommit debate

From: David Whysong (dwhysong@physics.ucsb.edu)
Date: Fri Mar 24 2000 - 21:48:29 EST

  • Next message: Ronald G. Minnich: "Re: Patch: BadRAM put to use"

    I'm writing a daemon that is meant to be used in conjunction with Rik van
    Riel's OOM killer patch. The following functionality is planned:

    1. Per-user memory quotas
            These are overcommitted; a user can exceed the quota so long as
            system memory is not low. Think of it as a minimum resource
            guarantee. There is a soft and a hard limit. If you exceed the
            soft limit when system memory is low, your processes are sent a
            SIGSTOP. If you exceed the hard limit, a process is selected and
            sent SIGTERM, then SIGKILL. Limits are specified in a
            configuration file.

    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.

    3. Execution on task startup
            It may be worth having the kernel signal or wake-up the daemon
            after a new task is started. I don't know how to do this, and I'm
            not sure it's even a good idea. Perhaps instead the daemon should
            run as a real-time task?

    Number 1 is mostly implemented right now (give me a few days before I
    release release the code).

    Questions:

    1. How can I avoid using stack or library functions, especially doing file
       IO? Right now I simply ignore the SIGHUP if system memory is low, but
       the daemon still must read the /proc/[PID] files periodically.

    2. I use mlockall() with MCL_FUTURE. The man page indicates that there is
       a limit to the number of locked pages. Could this be a problem on large
       machines, since I allocate several K of memory per user to store data?

    Any comments would be appreciated.

    Dave

    David Whysong dwhysong@physics.ucsb.edu
    Astrophysics graduate student University of California, Santa Barbara
    My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
    DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
    D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91

    -
    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 24 2000 - 22:40:03 EST