Messages in this thread | | | Date | Wed, 27 Apr 2011 14:08:18 +0900 | Subject | Re: [PATCH v2] fix get_scan_count for working well with small targets | From | Minchan Kim <> |
| |
Hi Kame,
On Wed, Apr 27, 2011 at 10:50 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > On Tue, 26 Apr 2011 13:59:34 -0700 > Andrew Morton <akpm@linux-foundation.org> wrote: > >> 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. >> > > ok, v2 here. How this looks ? > For memcg, I think I should add select_victim_node() for direct reclaim, > then, we'll be tune big memcg using small memory on a zone case. > > == > 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, the scan will be skipped for this time > and priority gets higher. This has some problems. > > 1. This increases priority as 1 without any scan. > To do scan in this priority, 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.)
Nice catch! It looks to be much enhance.
> But if the amount of pages is smaller than 16M, no scan at priority==0 > forever.
Before reviewing the code, I have a question about this. Now, in case of (priority = 0), we don't do shift operation with priority. So nr_saved_scan would be the number of lru list pages. ie, 16M. Why no-scan happens in case of (priority == 0 and 16M lru pages)? What am I missing now?
> > 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.
It makes sense.
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |