Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752269AbcD1MjJ (ORCPT ); Thu, 28 Apr 2016 08:39:09 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35278 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751435AbcD1MjG (ORCPT ); Thu, 28 Apr 2016 08:39:06 -0400 Date: Thu, 28 Apr 2016 14:39:04 +0200 From: Michal Hocko To: Vlastimil Babka Cc: Andrew Morton , Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML Subject: Re: [PATCH 14/14] mm, oom, compaction: prevent from should_compact_retry looping for ever for costly orders Message-ID: <20160428123904.GH31489@dhcp22.suse.cz> References: <1461181647-8039-1-git-send-email-mhocko@kernel.org> <1461181647-8039-15-git-send-email-mhocko@kernel.org> <5721D0EA.3020205@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5721D0EA.3020205@suse.cz> 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: 1363 Lines: 35 On Thu 28-04-16 10:59:22, Vlastimil Babka wrote: > On 04/20/2016 09:47 PM, Michal Hocko wrote: > >From: Michal Hocko > > > >"mm: consider compaction feedback also for costly allocation" has > >removed the upper bound for the reclaim/compaction retries based on the > >number of reclaimed pages for costly orders. While this is desirable > >the patch did miss a mis interaction between reclaim, compaction and the > >retry logic. > > Hmm perhaps reversing the order of patches 13 and 14 would be a bit safer > wrt future bisections then? Add compaction_zonelist_suitable() first with > the reasoning, and then immediately use it in the other patch. Hmm, I do not think the risk is high. This would require the allocate GFP_REPEAT large orders to the last drop which is not usual. I found the ordering more logical to argue about because this patch will be mostly noop for costly orders without 13 and !costly allocations retry endlessly anyway. So I would prefer this ordering even though there is a window where an extreme load can lockup. I do not expect people shooting their head during bisection. [...] > > > >[vbabka@suse.cz: fix classzone_idx vs. high_zoneidx usage in > >compaction_zonelist_suitable] > >Signed-off-by: Michal Hocko > > Acked-by: Vlastimil Babka Thanks! -- Michal Hocko SUSE Labs