Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932736AbdGKUkJ (ORCPT ); Tue, 11 Jul 2017 16:40:09 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:36314 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754818AbdGKUkG (ORCPT ); Tue, 11 Jul 2017 16:40:06 -0400 Date: Tue, 11 Jul 2017 13:40:04 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko cc: linux-mm@kvack.org, Tetsuo Handa , Oleg Nesterov , Andrea Argangeli , Andrew Morton , LKML Subject: Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap In-Reply-To: <20170711065834.GF24852@dhcp22.suse.cz> Message-ID: References: <20170626130346.26314-1-mhocko@kernel.org> <20170711065834.GF24852@dhcp22.suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) 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: 1675 Lines: 48 On Tue, 11 Jul 2017, Michal Hocko wrote: > This? > --- > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 5dc0ff22d567..e155d1d8064f 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -470,11 +470,14 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm) > { > struct mmu_gather tlb; > struct vm_area_struct *vma; > - bool ret = true; > > if (!down_read_trylock(&mm->mmap_sem)) > return false; > > + /* There is nothing to reap so bail out without signs in the log */ > + if (!mm->mmap) > + goto unlock; > + > /* > * Tell all users of get_user/copy_from_user etc... that the content > * is no longer stable. No barriers really needed because unmapping > @@ -508,9 +511,10 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm) > K(get_mm_counter(mm, MM_ANONPAGES)), > K(get_mm_counter(mm, MM_FILEPAGES)), > K(get_mm_counter(mm, MM_SHMEMPAGES))); > +unlock: > up_read(&mm->mmap_sem); > > - return ret; > + return true; > } > > #define MAX_OOM_REAP_RETRIES 10 Yes, this folded in with the original RFC patch appears to work better with light testing. However, I think MAX_OOM_REAP_RETRIES and/or the timeout of HZ/10 needs to be increased as well to address the issue that Tetsuo pointed out. The oom reaper shouldn't be required to do any work unless it is resolving a livelock, and that scenario should be relatively rare. The oom killer being a natural ultra slow path, I think it would be justifiable to wait longer or retry more times than simply 1 second before declaring that reaping is not possible. It reduces the likelihood of additional oom killing.