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 <[email protected]> > > 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 <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
