lkml.org 
[lkml]   [2000]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Overcommitable memory??
    Date
    On Mon, 20 Mar 2000 05:39:48 -0600, you wrote:
    >On Sun, 19 Mar 2000, David Whysong wrote:
    >>On Sun, 19 Mar 2000, Jesse Pollard wrote:
    >>>On Sun, 19 Mar 2000, James Sutherland wrote:
    >>>>On Sat, 18 Mar 2000 08:31:58 -0600, you wrote:
    >>>>
    >>>>> Users (and processes) will get an Out-Of-Resource
    >>>>> errors which the users can deal with.
    >>>>
    >>>>In practice, they usually just die.
    >>>
    >>>The user still gets the choice.
    >>
    >>No, this can't be allowed. What happens in the case of:
    >> OOM -> signal processes Out of Resources
    >> all processes decide to ignore the signal
    >
    >note: these are one specific user not the system - and what happens
    >when they ignore the signal - they are aborted.

    Just send SIGTERM. This gives them an opportunity to exit gracefully.
    If they ignore it, SIGKILL them.

    >>Once we are OOM, you can't give user-space any choices.
    >
    >YOU ARN'T OOM - a specific user is out of resources, not a catastrophic
    >failure.

    SOMETHING (the user, the process, the system, the cluster, whatever)
    is out of resources, so something has to give. Which unit has run out
    of resources doesn't matter - the issue is how we handle running out
    of resources in some category.

    >>Repeat after me:
    >> You can not solve the OOM problem in user space.
    >> You can not solve the OOM problem without killing processes.
    >> Resource limits are not a good solution to the OOM problem.
    >>
    >>I don't like resource limits. Using resource limits is similar to not
    >>having memory overcommit -- you waste a lot of system resources "just in
    >>case", the kernel needs to do a lot more accounting, and it's just
    >>horribly inefficient.
    >
    >Resource limits CAN prevent the OOM condition if
    > 1. the sum of all concurrent users is <= total resources
    > 2. users are not allowed to exceed their quota

    That's an extremely restrictive approach, but appropriate in some
    cases. We need those resource limits - but what's this got to do with
    overcommit??

    >>>>> If the proper resource allocation were given then usrs running wild
    >>>>> memory allocators would not be able to crash the system by causing
    >>>>> init to die.
    >>
    >>>>They shouldn't be able to anyway - Rik's patch should ensure that init
    >>>>will always survive, even if every other process on the box is hosed.
    >>>>(Of course, if init was the malfunctioning process to begin with...)
    >>
    >>If init malfunctions, you're hosed no matter what.
    >
    >It only aborts (normal situation) if the system is allowed to go OOM.

    It shouldn't abort then, either. If it needs more resources, Rik's
    patch will free them up for it; if not, it carries on as normal.

    >>>>>All else is a matter of implementation.
    >>>>
    >>>>The core problem remains. You, the user, have a finite amount of
    >>>>memory available to you, however that limit is defined. Once you run
    >>>>out, your processes will start dying.
    >>
    >>But that's not the problem! That's the way things have to be. You can't
    >>use more resources than there are available.
    >
    >No you can't - what you are doing is "giving" access to resources you
    >don't have. When the resources are then accessed - you die; and the system
    >with it.

    NO. The system does NOT die just because a process tried to allocate
    some memory it couldn't have! The PROCESS dies.

    >>>Yes - ME THE USER. I should not be able to cause the SYSTEM a problem.
    >>>I should not be able to cause OTHER users a problem.
    >>
    >>Ahh, no! You can only do this by setting up horribly restrictive quotas
    >>and effectively removing overcommit, which is terribly wasteful!
    >
    >not horribly - It does appear that way when you have never been forced to
    >live within a budget.

    Your system is extremely restrictive and paranoid. Since you brought
    up the money analogy, ask your bank if they carry the same amount of
    cash as they have on deposit in total?

    >>>>We need per-user resource limits, ideally - until then, everything is
    >>>>done with process granularity instead. This is a shortcoming we all
    >>>>know about already, but not one that is likely to be fixed any time
    >>>>soon.
    >>>
    >>>That is possibly why the OOM complaints will not go away.
    >>
    >>Well, my OOM complaints stem from the fact that right now OOM situations
    >>are functionally equivalent to crashing the machine.
    >
    >Can't be helped much, as long as resource control is missing.

    Yes it can. The machine should never crash, and init should never be
    terminated; provided init is still functional, it should be able to
    keep the other services going, even if all the other processes have to
    be killed to make space for it.


    James.

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.148 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site