Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933498AbcDLLxx (ORCPT ); Tue, 12 Apr 2016 07:53:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:45144 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932320AbcDLLxw (ORCPT ); Tue, 12 Apr 2016 07:53:52 -0400 Subject: Re: [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers To: Michal Hocko References: <1459855533-4600-1-git-send-email-mhocko@kernel.org> <1459855533-4600-10-git-send-email-mhocko@kernel.org> <570BB719.2030007@suse.cz> <20160411151410.GL23157@dhcp22.suse.cz> Cc: Andrew Morton , Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML From: Vlastimil Babka Message-ID: <570CE1CB.7070106@suse.cz> Date: Tue, 12 Apr 2016 13:53:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160411151410.GL23157@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1777 Lines: 36 On 04/11/2016 05:14 PM, Michal Hocko wrote: > On Mon 11-04-16 16:39:21, Vlastimil Babka wrote: >> On 04/05/2016 01:25 PM, Michal Hocko wrote: > [...] >>> +/* Compaction has failed and it doesn't make much sense to keep retrying. */ >>> +static inline bool compaction_failed(enum compact_result result) >>> +{ >>> + /* All zones where scanned completely and still not result. */ >> >> Hmm given that try_to_compact_pages() uses a max() on results, then in fact >> it takes only one zone to get this. Others could have been also SKIPPED or >> DEFERRED. Is that what you want? > > In short I didn't find any better way and still guarantee a some > guarantee of convergence. COMPACT_COMPLETE means that at least one zone > was completely scanned and led to no result. That zone would be > compact_suitable by definition. If I made DEFERRED or SKIPPED more > priorite (aka higher in the enum) then I could easily end up in a state > where all zones would return COMPACT_COMPLETE and few remaining would > just alternate returning their DEFFERED resp. SKIPPED. So while this > might sound like giving up too early I couldn't come up with anything > more specific that would lead to reliable results. > > I am open to any suggestions of course. I guess you would have to track each zone separately and make sure you've seen COMPACT_COMPLETE in all of them, although not necessary during the same zonelist attempt. But then do the same for reclaim, as you would also have to match COMPAT_SKIPPED and inability of reclaim... and that gets uglier and uglier, and also against the move to node-based reclaim... So there's a danger that you'll see COMPACT_COMPLETE on a small ZONE_DMA early on, before the larger zones even stop being deferred, but I don't see an easy solution.