From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751805AbcGNIc2 (ORCPT ); Thu, 14 Jul 2016 04:32:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:56759 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751512AbcGNIcO (ORCPT ); Thu, 14 Jul 2016 04:32:14 -0400 Subject: Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps To: Joonsoo Kim , Mel Gorman References: <1467403299-25786-1-git-send-email-mgorman@techsingularity.net> <1467403299-25786-9-git-send-email-mgorman@techsingularity.net> <20160707012038.GB27987@js1304-P5Q-DELUXE> <20160707101701.GR11498@techsingularity.net> <20160708024447.GB2370@js1304-P5Q-DELUXE> <20160708101147.GD11498@techsingularity.net> <20160714052332.GA29676@js1304-P5Q-DELUXE> Cc: Andrew Morton , Linux-MM , Rik van Riel , Johannes Weiner , LKML From: Vlastimil Babka Message-ID: <5b6b1490-1dbc-74fc-e129-947141a1bee3@suse.cz> Date: Thu, 14 Jul 2016 10:32:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160714052332.GA29676@js1304-P5Q-DELUXE> 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 07/14/2016 07:23 AM, Joonsoo Kim wrote: > On Fri, Jul 08, 2016 at 11:11:47AM +0100, Mel Gorman wrote: >> On Fri, Jul 08, 2016 at 11:44:47AM +0900, Joonsoo Kim wrote: >> >> It doesn't stop reclaiming for the lower zones. It's reclaiming the LRU >> for the whole node that may or may not have lower zone pages at the end >> of the LRU. If it does, then the allocation request will be satisfied. >> If it does not, then kswapd will think the node is balanced and get >> rewoken to do a zone-constrained reclaim pass. > > If zone-constrained request could go direct reclaim pass, there would > be no problem. But, please assume that request is zone-constrained > without __GFP_DIRECT_RECLAIM which is common for some device driver > implementation. And, please assume one more thing that this request > always comes with zone-unconstrained allocation request. In this case, > your max() logic will set kswapd_classzone_idx to highest zone index > and re-worken kswapd would not balance for low zone again. In the end, > zone-constrained allocation request without __GFP_DIRECT_RECLAIM could > fail. I don't think there's a problem in the scenario? Kswapd will keep being woken up and reclaim from the node lru. It will hit and free any low zone pages that are on the lru, even though it doesn't "balance for low zone". Eventually it will either satisfy the constrained allocation by reclaiming those low-zone pages during the repeated wakeups, or the low-zone wakeups will stop coming together with higher-zone wakeups and then it will reclaim the low-zone pages in a single low-zone wakeup. If the zone-constrained request is not allowed to fail, then it will just keep waking up kswapd and waiting for the progress. If it's allowed to fail (i.e. not __GFP_NOFAIL), but not allowed to direct reclaim, it goes "goto nopage" rather quickly in __alloc_pages_slowpath(), without any waiting for kswapd's progress, so there's not really much difference whether the kswapd wakeup picked up a low classzone or not. Note the __GFP_NOFAIL but ~__GFP_DIRECT_RECLAIM is a WARN_ON_ONCE() scenario, so definitely not common... > Thanks. >