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


Groups > linux.kernel > #1697007

Re: [PATCH] oom_reaper: close race without using oom_lock

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] oom_reaper: close race without using oom_lock
Date 2017-07-26 13:50 +0200
Message-ID <u7sZc-8do-3@gated-at.bofh.it> (permalink)
References (1 earlier) <u5HSG-6sw-7@gated-at.bofh.it> <u5Ic2-6B7-31@gated-at.bofh.it> <u6dfQ-sX-13@gated-at.bofh.it> <u6Fc6-1cC-19@gated-at.bofh.it> <u7sPv-89V-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed 26-07-17 20:33:21, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Sun 23-07-17 09:41:50, Tetsuo Handa wrote:
> > > So, how can we verify the above race a real problem?
> > 
> > Try to simulate a _real_ workload and see whether we kill more tasks
> > than necessary. 
> 
> Whether it is a _real_ workload or not cannot become an answer.
> 
> If somebody is trying to allocate hundreds/thousands of pages after memory of
> an OOM victim was reaped, avoiding this race window makes no sense; next OOM
> victim will be selected anyway. But if somebody is trying to allocate only one
> page and then is planning to release a lot of memory, avoiding this race window
> can save somebody from being OOM-killed needlessly. This race window depends on
> what the threads are about to do, not whether the workload is natural or
> artificial.

And with a desparate lack of crystal ball we cannot do much about that
really.

> My question is, how can users know it if somebody was OOM-killed needlessly
> by allowing MMF_OOM_SKIP to race.

Is it really important to know that the race is due to MMF_OOM_SKIP?
Isn't it sufficient to see that we kill too many tasks and then debug it
further once something hits that?

[...]
> Is it guaranteed that __node_reclaim() never (even indirectly) waits for
> __GFP_DIRECT_RECLAIM && !__GFP_NORETRY memory allocation?

this is a direct reclaim which can go down to slab shrinkers with all
the usual fun...

> >                                      Such races are unfortunate but
> > unavoidable unless we synchronize oom kill with any memory freeing which
> > smells like a no-go to me. We can try a last allocation attempt right
> > before we go and kill something (which still wouldn't be race free) but
> > that might cause other issues - e.g. prolonged trashing without ever
> > killing something - but I haven't evaluated those to be honest.
> 
> Yes, postpone last get_page_from_freelist() attempt till oom_kill_process()
> will be what we would afford at best.

as I've said this would have to be evaluated very carefully and a strong
usecase would have to be shown.
-- 
Michal Hocko
SUSE Labs

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


Thread

[PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-18 16:10 +0200
  Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-18 16:20 +0200
    Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-18 23:00 +0200
      Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-20 16:20 +0200
        Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-20 23:50 +0200
          Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-21 17:10 +0200
            Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-21 17:20 +0200
              Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-21 17:40 +0200
                Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-23 02:50 +0200
                Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-23 05:10 +0200
                Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-24 08:40 +0200
                Re: [PATCH] oom_reaper: close race without using oom_lock Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-07-26 13:40 +0200
                Re: [PATCH] oom_reaper: close race without using oom_lock Michal Hocko <mhocko@kernel.org> - 2017-07-26 13:50 +0200
  Re: [PATCH] oom_reaper: close race without using oom_lock Johannes Weiner <hannes@cmpxchg.org> - 2017-07-18 16:20 +0200

csiph-web