Re: [PATCH] fix get_scan_count for working well with small targets

From: Andrew Morton
Date: Tue Apr 26 2011 - 16:59:50 EST


On Tue, 26 Apr 2011 18:17:24 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:

> At memory reclaim, we determine the number of pages to be scanned
> per zone as
> (anon + file) >> priority.
> Assume
> scan = (anon + file) >> priority.
>
> If scan < SWAP_CLUSTER_MAX, shlink_list will be skipped for this
> priority and results no-sacn. This has some problems.
>
> 1. This increases priority as 1 without any scan.
> To do scan in DEF_PRIORITY always, amount of pages should be larger than
> 512M. If pages>>priority < SWAP_CLUSTER_MAX, it's recorded and scan will be
> batched, later. (But we lose 1 priority.)
> But if the amount of pages is smaller than 16M, no scan at priority==0
> forever.
>
> 2. If zone->all_unreclaimabe==true, it's scanned only when priority==0.
> So, x86's ZONE_DMA will never be recoverred until the user of pages
> frees memory by itself.
>
> 3. With memcg, the limit of memory can be small. When using small memcg,
> it gets priority < DEF_PRIORITY-2 very easily and need to call
> wait_iff_congested().
> For doing scan before priorty=9, 64MB of memory should be used.
>
> This patch tries to scan SWAP_CLUSTER_MAX of pages in force...when
>
> 1. the target is enough small.
> 2. it's kswapd or memcg reclaim.
>
> Then we can avoid rapid priority drop and may be able to recover
> all_unreclaimable in a small zones.

What about simply removing the nr_saved_scan logic and permitting small
scans? That simplifies the code and I bet it makes no measurable
performance difference.

(A good thing to do here would be to instrument the code and determine
the frequency with which we perform short scans, as well as their
shortness. ie: a histogram).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/