linux-kernel - Re: [PATCH] mm, vmscan: Give up balancing node for high order allocations earlier

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:	Tue, 12 Jul 2016 09:33:42 +0100
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Hillf Danton <hillf.zj@...baba-inc.com>
Cc:	'Andrew Morton' <akpm@...ux-foundation.org>,
	'Johannes Weiner' <hannes@...xchg.org>,
	'Vlastimil Babka' <vbabka@...e.cz>,
	'linux-kernel' <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: [PATCH] mm, vmscan: Give up balancing node for high order
 allocations earlier

On Tue, Jul 12, 2016 at 02:32:45PM +0800, Hillf Danton wrote:
> > > To avoid excessive reclaim, we give up rebalancing for high order
> > > allocations right after reclaiming enough pages.
> > 
> > hm.  What are the observed runtime effects of this change?  Any testing
> > results?
> > 
> This work was based on Mel's work, Sir,
> "[PATCH 00/27] Move LRU page reclaim from zones to nodes v7".
> 

I believe Andrew understands that but the question is what is the
observed runtime effect of the patch?

> In "[PATCH 06/27] mm, vmscan: Make kswapd reclaim in terms of nodes", 
> fragmentation detection is introduced to avoid excessive reclaim. We bail 
> out of balancing for high-order allocations if the pages reclaimed at the 
> __current__ reclaim priority are two times more than required.
> 
> In this work we give up reclaiming for high-order allocations if the 
> __total__ number of pages reclaimed, from the first priority to the 
> current priority, is more than needed, and in net result we reclaim less 
> pages.
> 

While it's clear what it does, it is not clear if it is an improvement. I had
read the patch, considered merging it and decided against it. This decision
was based on the fact the series did not appear to be over-reclaiming for
high-order pages when compared with zone-lru.

Did you test this patch with a workload that requires a lot of high-order
pages and see if kswapd was over-reclaiming and that this patch addressed
the issue?

-- 
Mel Gorman
SUSE Labs