linux-kernel - Re: [PATCH 04/31] mm, vmscan: begin reclaiming pages on a per-node basis

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:	Thu, 7 Jul 2016 10:48:08 +0100
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux-MM <linux-mm@...ck.org>, Rik van Riel <riel@...riel.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Johannes Weiner <hannes@...xchg.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 04/31] mm, vmscan: begin reclaiming pages on a per-node
 basis

On Thu, Jul 07, 2016 at 10:12:12AM +0900, Joonsoo Kim wrote:
> > @@ -1402,6 +1406,11 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> >  
> >  		VM_BUG_ON_PAGE(!PageLRU(page), page);
> >  
> > +		if (page_zonenum(page) > sc->reclaim_idx) {
> > +			list_move(&page->lru, &pages_skipped);
> > +			continue;
> > +		}
> > +
> 
> I think that we don't need to skip LRU pages in active list. What we'd
> like to do is just skipping actual reclaim since it doesn't make
> freepage that we need. It's unrelated to skip the page in active list.
> 

Why?

The active aging is sometimes about simply aging the LRU list. Aging the
active list based on the timing of when a zone-constrained allocation arrives
potentially introduces the same zone-balancing problems we currently have
and applying them to node-lru.

> And, I have a concern that if inactive LRU is full with higher zone's
> LRU pages, reclaim with low reclaim_idx could be stuck.

That is an outside possibility but unlikely given that it would require
that all outstanding allocation requests are zone-contrained. If it happens
that a premature OOM is encountered while the active list is large then
inactive_list_is_low could take scan_control as a parameter and use a
different ratio for zone-contrained allocations if scan priority is elevated.

It would be preferred to have an actual test case for this so the
altered ratio can be tested instead of introducing code that may be
useless or dead.

-- 
Mel Gorman
SUSE Labs