From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756518AbcA2PY1 (ORCPT ); Fri, 29 Jan 2016 10:24:27 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:34686 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756421AbcA2PYY (ORCPT ); Fri, 29 Jan 2016 10:24:24 -0500 Date: Fri, 29 Jan 2016 16:24:22 +0100 From: Michal Hocko To: Johannes Weiner Cc: Andrew Morton , Linus Torvalds , Mel Gorman , David Rientjes , Tetsuo Handa , Hillf Danton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, LKML Subject: Re: [PATCH 4/3] mm, oom: drop the last allocation attempt before out_of_memory Message-ID: <20160129152422.GG32174@dhcp22.suse.cz> References: <1450203586-10959-1-git-send-email-mhocko@kernel.org> <1454013603-3682-1-git-send-email-mhocko@kernel.org> <20160128213634.GA4903@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160128213634.GA4903@cmpxchg.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 On Thu 28-01-16 16:36:34, Johannes Weiner wrote: > On Thu, Jan 28, 2016 at 09:40:03PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > __alloc_pages_may_oom has been doing get_page_from_freelist with > > ALLOC_WMARK_HIGH target before going out_of_memory and invoking the oom > > killer. This has two reasons as explained by Andrea: > > " > > : the reason for the high wmark is to reduce the likelihood of livelocks > > : and be sure to invoke the OOM killer, if we're still under pressure > > : and reclaim just failed. The high wmark is used to be sure the failure > > : of reclaim isn't going to be ignored. If using the min wmark like > > : you propose there's risk of livelock or anyway of delayed OOM killer > > : invocation. > > : > > : The reason for doing one last wmark check (regardless of the wmark > > : used) before invoking the oom killer, was just to be sure another OOM > > : killer invocation hasn't already freed a ton of memory while we were > > : stuck in reclaim. A lot of free memory generated by the OOM killer, > > : won't make a parallel reclaim more likely to succeed, it just creates > > : free memory, but reclaim only succeeds when it finds "freeable" memory > > : and it makes progress in converting it to free memory. So for the > > : purpose of this last check, the high wmark would work fine as lots of > > : free memory would have been generated in such case. > > " > > > > This is no longer a concern after "mm, oom: rework oom detection" > > because should_reclaim_retry performs the water mark check right before > > __alloc_pages_may_oom is invoked. Remove the last moment allocation > > request as it just makes the code more confusing and doesn't really > > serve any purpose because a success is basically impossible otherwise > > should_reclaim_retry would force the reclaim to retry. So this is > > merely a code cleanup rather than a functional change. > > > > Signed-off-by: Michal Hocko > > The check has to happen while holding the OOM lock, otherwise we'll > end up killing much more than necessary when there are many racing > allocations. My testing shows that this doesn't trigger even during oom flood testing. So I am not really convinced it does anything useful. > Please drop this patch. Sure I do not insist... -- Michal Hocko SUSE Labs