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

Groups > linux.kernel > #1417635

Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully

Show all headers | View raw

On Wed 08-06-16 23:55:24, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Wed 08-06-16 06:49:24, Tetsuo Handa wrote:
> > > Michal Hocko wrote:
> > > > OK, so you are arming the timer for each mark_oom_victim regardless
> > > > of the oom context. This means that you have replaced one potential
> > > > lockup by other potential livelocks. Tasks from different oom domains
> > > > might interfere here...
> > > > 
> > > > Also this code doesn't even seem easier. It is surely less lines of
> > > > code but it is really hard to realize how would the timer behave for
> > > > different oom contexts.
> > > 
> > > If you worry about interference, we can use per signal_struct timestamp.
> > > I used per task_struct timestamp in my earlier versions (where per
> > > task_struct TIF_MEMDIE check was used instead of per signal_struct
> > > oom_victims).
> > 
> > This would allow pre-mature new victim selection for very large victims
> > (note that exit_mmap can take a while depending on the mm size). It also
> > pushed the timeout heuristic for everybody which will sooner or later
> > open a question why is this $NUMBER rathen than $NUMBER+$FOO.
> 
> You are again worrying about wrong problem. You are ignoring distinction
> between genuine lock up (real problem for you) and effectively locked up
> (real problem for administrators).

No, I just do care more about a sane and consistent behavior rather than
a random one which is inherent to timeout based solutions.

[...]
> > To be honest I would rather explore ways to handle kthread case (which
> > is the only real one IMHO from the two) gracefully and made them a
> > nonissue - e.g. enforce EFAULT on a dead mm during the kthread page fault
> > or something similar.
> 
> You are always living in a world with plenty resource. You tend to ignore
> CONFIG_MMU=n kernels.

You keep repeating !CONFIG_MMU case but never shown a single evidence
this is an actual problem for those platforms. If this turns out to
be a real problem I am willing to spend time on it and try to find a
solution.

I am sorry, I have left most of your email without any reaction. I
just don't believe repeating the same arguments is anyhow useful or
productive. Quite some time ago I've told that I strongly believe that
doing any timeout based heuristic should be only the last resort when we
fail all other ways to mitigate the issue. I think I've shown that there
is a path, which btw. doesn't add too much code into the oom path. All
the patches are self rather small incrementally improve the situation. I
have already told you that you, as a reviewer, are free to nack those
patches if you believe they are incorrect, unmaintainable or actively
harmful to the common case. Unless you do so with a proper justification
I will not react to any timeout based solutions.

I will post the full series with all the remaining fixups tomorrow and
let all the reviewers to judge. I strongly believe that it puts some
order to the code and makes it easier to reason about. If this view
is not shared by others I can back off and not pursue this path any
longer.
-- 
Michal Hocko
SUSE Labs

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

Thread

[PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:20 +0200
  [PATCH 08/10] mm, oom: task_will_free_mem should skip oom_reaped tasks Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:20 +0200
  [RFC PATCH 09/10] mm, oom_reaper: do not attempt to reap a task more than twice Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:20 +0200
  [PATCH 07/10] mm, oom: fortify task_will_free_mem Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:20 +0200
  [PATCH 03/10] proc, oom_adj: extract oom_score_adj setting into a helper Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:30 +0200
  [PATCH 02/10] proc, oom: drop bogus sighand lock Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:30 +0200
  [RFC PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:30 +0200
    Re: [RFC PATCH 10/10] mm, oom: hide mm which is shared with kthread or global init Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-03 17:20 +0200
      Re: [RFC PATCH 10/10] mm, oom: hide mm which is shared with kthread  or global init Michal Hocko <mhocko@kernel.org> - 2016-06-06 10:20 +0200
      Re: [RFC PATCH 10/10] mm, oom: hide mm which is shared with kthread  or global init Michal Hocko <mhocko@kernel.org> - 2016-06-06 15:30 +0200
        Re: [RFC PATCH 10/10] mm, oom: hide mm which is shared with kthread  or global init Michal Hocko <mhocko@kernel.org> - 2016-06-07 08:30 +0200
  [PATCH 01/10] proc, oom: drop bogus task_lock and mm check Michal Hocko <mhocko@kernel.org> - 2016-06-03 11:30 +0200
  Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-03 14:10 +0200
    Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-03 14:30 +0200
      Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-03 14:30 +0200
        Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-04 13:00 +0200
          Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-06 10:40 +0200
      Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-03 17:20 +0200
        Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-06 10:40 +0200
          Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-07 16:40 +0200
            Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-07 17:10 +0200
              Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-08 00:00 +0200
                Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-08 09:30 +0200
                Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2016-06-08 17:00 +0200
                Re: [PATCH 0/10 -v3] Handle oom bypass more gracefully Michal Hocko <mhocko@kernel.org> - 2016-06-08 18:10 +0200

csiph-web