[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Some questions about linux kernel.
    On Wed, 15 Mar 2000, Paul Jakma wrote:

    > On Tue, 14 Mar 2000, Rik van Riel wrote:
    > > Indeed. There is always a way to fool any OOM killer.
    > > The only thing that could save us here are proper
    > > per-user resource limits,
    > so isn't what should be concentrated on? Per user limits are a cleaner
    > way of fixing the problem.

    They would AVOID the problem in a lot of cases - but not always. Yes, we
    should have per-user resource limits. Yes, they would help prevent
    malloc-bombs from being effective. No, they will not *prevent* OOM
    situations arising.

    > i guess though it's a 2.5 thing. Rik, do you know of anyone
    > investigating per-user limits for 2.5? (a lot of linux users would
    > like to see it.. hint hint..)
    > :)
    > > but even then we'd still want
    > > an emergency OOM killer to rescue the system in situations
    > > where we hit the wall...
    > >
    > OOM is a stopgap. Ideally we should be able to set ironclad policies so
    > that we never encounter OOM.

    I doubt that could really be achieved. Dynamically reducing user rlimits
    to try to prevent them overloading the system would ALMOST achieve this -
    but what if a root process blows up? What if a couple of users all hit
    their resource limits at once? While individually they may not have high
    enough resource limits to OOM the box, a group of users would still be
    able to.

    We can, of course, make OOM *almost* impossible. Per-user rlimits, plus a
    first-line userspace daemon (to prevent true OOM situations arising) will
    make this almost impossible - but never completely.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.020 / U:92.804 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site