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]

Date:	Mon, 18 Jul 2016 08:51:16 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	Mel Gorman <mgorman@...hsingularity.net>,
	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/18/2016 07:07 AM, Joonsoo Kim wrote:
> On Thu, Jul 14, 2016 at 10:32:09AM +0200, Vlastimil Babka wrote:
>> On 07/14/2016 07:23 AM, Joonsoo Kim wrote:
>>
>> 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
>
> Yes, probability of this would be low.
>
>> 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
>
> Hmm... Even if allocation could fail, we should do our best to prevent
> failure. Relying on luck isn't good idea to me.

But "Doing our best" has to have some sane limits. Allocation, that 
cannot direct reclaim, already relies on luck. And we are not really 
changing this. The allocation will "goto nopage" before kswapd can even 
wake up and start doing something, regardless of classzone_idx used.

> Thanks.
>
>> __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@...ck.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>