linux-kernel - Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5b6b1490-1dbc-74fc-e129-947141a1bee3@suse.cz>
Date:	Thu, 14 Jul 2016 10:32:09 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Mel Gorman <mgorman@...hsingularity.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>, Rik van Riel <riel@...riel.com>,
	Johannes Weiner <hannes@...xchg.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether
 kswapd sleeps

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.
>