Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966734AbbLQNC2 (ORCPT ); Thu, 17 Dec 2015 08:02:28 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37618 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934221AbbLQNC1 (ORCPT ); Thu, 17 Dec 2015 08:02:27 -0500 Date: Thu, 17 Dec 2015 14:02:24 +0100 From: Michal Hocko To: Andrew Morton Cc: Mel Gorman , Tetsuo Handa , David Rientjes , Linus Torvalds , Oleg Nesterov , Hugh Dickins , Andrea Argangeli , Rik van Riel , linux-mm@kvack.org, LKML Subject: Re: [PATCH 1/2] mm, oom: introduce oom reaper Message-ID: <20151217130223.GE18625@dhcp22.suse.cz> References: <1450204575-13052-1-git-send-email-mhocko@kernel.org> <20151216165035.38a4d9b84600d6348a3cf4bf@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216165035.38a4d9b84600d6348a3cf4bf@linux-foundation.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2133 Lines: 58 On Wed 16-12-15 16:50:35, Andrew Morton wrote: > On Tue, 15 Dec 2015 19:36:15 +0100 Michal Hocko wrote: [...] > > +static void oom_reap_vmas(struct mm_struct *mm) > > +{ > > + int attempts = 0; > > + > > + while (attempts++ < 10 && !__oom_reap_vmas(mm)) > > + schedule_timeout(HZ/10); > > schedule_timeout() in state TASK_RUNNING doesn't do anything. Use > msleep() or msleep_interruptible(). I can't decide which is more > appropriate - it only affects the load average display. Ups. You are right. I will go with msleep_interruptible(100). > Which prompts the obvious question: as the no-operativeness of this > call wasn't noticed in testing, why do we have it there... Well, the idea was that an interfering mmap_sem operation which holds it for write might block us for a short time period - e.g. when not depending on an allocation or accessing the memory reserves helps to progress the allocation. If the holder of the semaphore is stuck then the retry is pointless. On the other hand the retry shouldn't be harmful. All in all this is just a heuristic and we do not depend on it. I guess we can drop it and nobody would actually notice. Let me know if you prefer that and I will respin the patch. > I guess it means that the __oom_reap_vmas() success rate is nice anud > high ;) I had a debugging trace_printks around this and there were no reties during my testing so I was probably lucky to not trigger the mmap_sem contention. --- diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 48025a21f8c4..f53f87cfd899 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -469,7 +469,7 @@ static void oom_reap_vmas(struct mm_struct *mm) int attempts = 0; while (attempts++ < 10 && !__oom_reap_vmas(mm)) - schedule_timeout(HZ/10); + msleep_interruptible(100); /* Drop a reference taken by wake_oom_reaper */ mmdrop(mm); -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/