[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1807241355200.191886@chino.kir.corp.google.com>
Date: Tue, 24 Jul 2018 13:55:33 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...nel.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm, oom: remove oom_lock from oom_reaper
On Thu, 19 Jul 2018, Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
>
> oom_reaper used to rely on the oom_lock since e2fe14564d33 ("oom_reaper:
> close race with exiting task"). We do not really need the lock anymore
> though. 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run
> concurrently") has removed serialization with the exit path based on the
> mm reference count and so we do not really rely on the oom_lock anymore.
>
> Tetsuo was arguing that at least MMF_OOM_SKIP should be set under the
> lock to prevent from races when the page allocator didn't manage to get
> the freed (reaped) memory in __alloc_pages_may_oom but it sees the flag
> later on and move on to another victim. Although this is possible in
> principle let's wait for it to actually happen in real life before we
> make the locking more complex again.
>
> Therefore remove the oom_lock for oom_reaper paths (both exit_mmap and
> oom_reap_task_mm). The reaper serializes with exit_mmap by mmap_sem +
> MMF_OOM_SKIP flag. There is no synchronization with out_of_memory path
> now.
>
> Suggested-by: David Rientjes <rientjes@...gle.com>
> Signed-off-by: Michal Hocko <mhocko@...e.com>
Acked-by: David Rientjes <rientjes@...gle.com>
Powered by blists - more mailing lists