From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by kanga.kvack.org (Postfix) with ESMTP id 7B0226B025F for ; Thu, 14 Jul 2016 04:32:14 -0400 (EDT) Received: by mail-lf0-f70.google.com with SMTP id p41so48437088lfi.0 for ; Thu, 14 Jul 2016 01:32:14 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id fw9si1283368wjb.14.2016.07.14.01.32.12 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Jul 2016 01:32:12 -0700 (PDT) Subject: Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps 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> From: Vlastimil Babka Message-ID: <5b6b1490-1dbc-74fc-e129-947141a1bee3@suse.cz> Date: Thu, 14 Jul 2016 10:32:09 +0200 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: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Mel Gorman Cc: Andrew Morton , Linux-MM , Rik van Riel , Johannes Weiner , LKML 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. > -- 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