linux-kernel - Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

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, 25 Jul 2016 10:20:14 +0100
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Michal Hocko <mhocko@...e.cz>,
	Vlastimil Babka <vbabka@...e.cz>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/5] mm, vmscan: Do not account skipped pages as scanned

On Mon, Jul 25, 2016 at 05:04:56PM +0900, Minchan Kim wrote:
> > @@ -1429,6 +1429,9 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
> >  			continue;
> >  		}
> >  
> > +		/* Pages skipped do not contribute to scan */
> > +		scan++;
> > +
> 
> As I mentioned in previous version, under irq-disabled-spin-lock, such
> unbounded operation would make the latency spike worse if there are
> lot of pages we should skip.
> 
> Don't we take care it?

It's not unbounded, it's bound by the size of the LRU list and it's not
going to be enough to trigger a warning. While the lock hold time may be
undesirable, unlocking it every SWAP_CLUSTER_MAX pages may increase overall
contention. There also is the question of whether skipped pages should be
temporarily putback before unlocking the LRU to avoid isolated pages being
unavailable for too long. It also cannot easily just return early without
prematurely triggering OOM due to a lack of progress. I didn't feel the
complexity was justified.

-- 
Mel Gorman
SUSE Labs