linux-kernel - Re: [patch 3/8] mm: vmscan: save work scanning (almost) empty LRU lists

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: <20121213193820.GC6317@cmpxchg.org>
Date:	Thu, 13 Dec 2012 14:38:20 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/8] mm: vmscan: save work scanning (almost) empty LRU
 lists

On Thu, Dec 13, 2012 at 04:43:46PM +0100, Michal Hocko wrote:
> On Wed 12-12-12 16:43:35, Johannes Weiner wrote:
> > In certain cases (kswapd reclaim, memcg target reclaim), a fixed
> > minimum amount of pages is scanned from the LRU lists on each
> > iteration, to make progress.
> > 
> > Do not make this minimum bigger than the respective LRU list size,
> > however, and save some busy work trying to isolate and reclaim pages
> > that are not there.
> > 
> > Signed-off-by: Johannes Weiner <hannes@...xchg.org>
> 
> Hmm, shrink_lruvec would do:
> 	nr_to_scan = min_t(unsigned long,
> 			   nr[lru], SWAP_CLUSTER_MAX);
> 	nr[lru] -= nr_to_scan;
> and isolate_lru_pages does
> 	for (scan = 0; scan < nr_to_scan && !list_empty(src); scan++)
> so it shouldn't matter and we shouldn't do any additional loops, right?
> 
> Anyway it would be beter if get_scan_count wouldn't ask for more than is
> available.

Consider the inactive_list_is_low() check (especially expensive for
memcg anon), lru_add_drain(), lru lock acquisition...

And as I wrote to Mel in the other email, this can happen a lot when
you have memory cgroups in a multi-node environment.

> Reviewed-by: Michal Hocko <mhocko@...e.cz>

Thanks!

> > @@ -1748,15 +1748,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
> >  out:
> >  	for_each_evictable_lru(lru) {
> >  		int file = is_file_lru(lru);
> > +		unsigned long size;
> >  		unsigned long scan;
> >  
> > -		scan = get_lru_size(lruvec, lru);
> > +		size = get_lru_size(lruvec, lru);
> +		size = scan = get_lru_size(lruvec, lru);
> 
> >  		if (sc->priority || noswap) {
> > -			scan >>= sc->priority;
> > +			scan = size >> sc->priority;
> >  			if (!scan && force_scan)
> > -				scan = SWAP_CLUSTER_MAX;
> > +				scan = min(size, SWAP_CLUSTER_MAX);
> >  			scan = div64_u64(scan * fraction[file], denominator);
> > -		}
> > +		} else
> > +			scan = size;
> 
> And this is not necessary then but this is totally nit.

Do you actually find this more readable?  Setting size = scan and then
later scan = size >> sc->priority? :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/