From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by kanga.kvack.org (Postfix) with ESMTP id F08076B0253 for ; Tue, 12 Apr 2016 07:53:51 -0400 (EDT) Received: by mail-wm0-f41.google.com with SMTP id v188so123796303wme.1 for ; Tue, 12 Apr 2016 04:53:51 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id q67si5831749wme.44.2016.04.12.04.53.50 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 12 Apr 2016 04:53:50 -0700 (PDT) Subject: Re: [PATCH 09/11] mm, compaction: Abstract compaction feedback to helpers 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> From: Vlastimil Babka Message-ID: <570CE1CB.7070106@suse.cz> Date: Tue, 12 Apr 2016 13:53:47 +0200 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: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Andrew Morton , Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML 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. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 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.