From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by kanga.kvack.org (Postfix) with ESMTP id DC27D6B0253 for ; Fri, 29 Jan 2016 10:24:24 -0500 (EST) Received: by mail-wm0-f47.google.com with SMTP id l66so71802390wml.0 for ; Fri, 29 Jan 2016 07:24:24 -0800 (PST) Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com. [74.125.82.67]) by mx.google.com with ESMTPS id v186si11613230wmb.62.2016.01.29.07.24.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jan 2016 07:24:24 -0800 (PST) Received: by mail-wm0-f67.google.com with SMTP id l66so10474236wml.2 for ; Fri, 29 Jan 2016 07:24:23 -0800 (PST) Date: Fri, 29 Jan 2016 16:24:22 +0100 From: Michal Hocko 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> Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: Andrew Morton , Linus Torvalds , Mel Gorman , David Rientjes , Tetsuo Handa , Hillf Danton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, LKML 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org