Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1308571

Re: [PATCH] mm,oom: Re-enable OOM killer using timers.

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] mm,oom: Re-enable OOM killer using timers.
Date 2016-01-13 17:30 +0100
Message-ID <qQwt5-2jv-31@gated-at.bofh.it> (permalink)
References <qOgVs-7pv-7@gated-at.bofh.it> <qQizM-PV-11@gated-at.bofh.it> <qQsz9-7YE-39@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed 13-01-16 21:11:30, Tetsuo Handa wrote:
[...]
> Those who use panic_on_oom = 1 expect that the system triggers kernel panic
> rather than stall forever. This is a translation of administrator's wish that
> "Please press SysRq-c on behalf of me if the memory exhausted. In that way,
> I don't need to stand by in front of the console twenty-four seven."
> 
> Those who use panic_on_oom = 0 expect that the OOM killer solves OOM condition
> rather than stall forever. This is a translation of administrator's wish that
> "Please press SysRq-f on behalf of me if the memory exhausted. In that way,
> I don't need to stand by in front of the console twenty-four seven."

I think you are missing an important point. There is _no reliable_ way
to resolve the OOM condition in general except to panic the system. Even
killing all user space tasks might not be sufficient in general because
they might be blocked by an unkillable context (e.g. kernel thread).
So if you need a reliable behavior then either use panic_on_oom=1 or
provide a measure to panic after fixed timeout if the OOM cannot get
resolved. We have seen patches in that regards but there was no general
interest in them to merge them.

All we can do is a best effort approach which tries to be optimized to
reduce the impact of an unexpected SIGKILL sent to a "random" task. And
this is a reasonable objective IMHO. This works well in 99% of cases.
You can argue you do care about that 1% and I sympathy with you but
steps to mitigate those shouldn't involve steps which bring another
level of non-determinism into an already complicated system. This was
the biggest issue of the early OOM killer.

-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] mm,oom: Re-enable OOM killer using timers. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-01-07 12:30 +0100
  Re: [PATCH] mm,oom: Re-enable OOM killer using timers. David Rientjes <rientjes@google.com> - 2016-01-13 02:40 +0100
    Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-01-13 13:20 +0100
      Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Michal Hocko <mhocko@kernel.org> - 2016-01-13 17:30 +0100
        Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Johannes Weiner <hannes@cmpxchg.org> - 2016-01-13 18:00 +0100
          Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Michal Hocko <mhocko@kernel.org> - 2016-01-13 19:10 +0100
            Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-01-14 12:30 +0100
              Re: [PATCH] mm,oom: Re-enable OOM killer using timers. David Rientjes <rientjes@google.com> - 2016-01-14 23:10 +0100
                Re: [PATCH] mm,oom: Re-enable OOM killer using timers. Johannes Weiner <hannes@cmpxchg.org> - 2016-01-15 00:00 +0100
                Re: [PATCH] mm,oom: Re-enable OOM killer using timers. David Rientjes <rientjes@google.com> - 2016-01-15 00:20 +0100

csiph-web