Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753267AbdGXGjd (ORCPT ); Mon, 24 Jul 2017 02:39:33 -0400 Received: from mail-pg0-f44.google.com ([74.125.83.44]:35375 "EHLO mail-pg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbdGXGjY (ORCPT ); Mon, 24 Jul 2017 02:39:24 -0400 Date: Sun, 23 Jul 2017 23:39:15 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Michal Hocko cc: Hugh Dickins , Andrea Arcangeli , Tetsuo Handa , David Rientjes , Oleg Nesterov , Andrew Morton , LKML , linux-mm@kvack.org Subject: Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap In-Reply-To: <20170720130541.GH9058@dhcp22.suse.cz> Message-ID: References: <20170626130346.26314-1-mhocko@kernel.org> <20170629084621.GE31603@dhcp22.suse.cz> <20170719055542.GA22162@dhcp22.suse.cz> <20170720130541.GH9058@dhcp22.suse.cz> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1029 Lines: 24 On Thu, 20 Jul 2017, Michal Hocko wrote: > On Wed 19-07-17 18:18:27, Hugh Dickins wrote: > > > > But I haven't looked at the oom_kill or oom_reaper end of it at all, > > perhaps you have an overriding argument on the placement from that end. > > Well, the main problem here is that the oom_reaper tries to > MADV_DONTNEED the oom victim and then hide it from the oom killer (by > setting MMF_OOM_SKIP) to guarantee a forward progress. In order to do > that it needs mmap_sem for read. Currently we try to avoid races with > the eixt path by checking mm->mm_users and that can lead to premature > MMF_OOM_SKIP and that in turn to additional oom victim(s) selection > while the current one is still tearing the address space down. > > One way around that is to allow final unmap race with the oom_reaper > tear down. > > I hope this clarify the motivation Thanks, yes, if you have a good reason of that kind, then I agree that it's appropriate to leave the down_write(mmap_sem) until reaching the free_pgtables() stage. Hugh