From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id B17368D0001 for ; Fri, 26 Nov 2010 04:18:28 -0500 (EST) Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id oAQ9IPNO007066 for (envelope-from kosaki.motohiro@jp.fujitsu.com); Fri, 26 Nov 2010 18:18:26 +0900 Received: from smail (m6 [127.0.0.1]) by outgoing.m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 977AC45DE4E for ; Fri, 26 Nov 2010 18:18:25 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (s6.gw.fujitsu.co.jp [10.0.50.96]) by m6.gw.fujitsu.co.jp (Postfix) with ESMTP id 672E345DE4C for ; Fri, 26 Nov 2010 18:18:25 +0900 (JST) Received: from s6.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id 2E7801DB8012 for ; Fri, 26 Nov 2010 18:18:25 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103]) by s6.gw.fujitsu.co.jp (Postfix) with ESMTP id DB8D71DB8014 for ; Fri, 26 Nov 2010 18:18:21 +0900 (JST) From: KOSAKI Motohiro Subject: Re: Free memory never fully used, swapping In-Reply-To: <1290739243.12777.17.camel@sli10-conroe> References: <20101126110244.B6DC.A69D9226@jp.fujitsu.com> <1290739243.12777.17.camel@sli10-conroe> Message-Id: <20101126181604.B6E4.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 26 Nov 2010 18:18:21 +0900 (JST) Sender: owner-linux-mm@kvack.org To: Shaohua Li Cc: kosaki.motohiro@jp.fujitsu.com, Mel Gorman , Simon Kirby , "linux-mm@kvack.org" , linux-kernel , Dave Hansen List-ID: > On Fri, 2010-11-26 at 10:31 +0800, KOSAKI Motohiro wrote: > > > record the order seems not sufficient. in balance_pgdat(), the for look > > > exit only when: > > > priority <0 or sc.nr_reclaimed >= SWAP_CLUSTER_MAX. > > > but we do if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) > > > order = sc.order = 0; > > > this means before we set order to 0, we already reclaimed a lot of > > > pages, so I thought we need set order to 0 earlier before there are > > > enough free pages. below is a debug patch. > > > > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index d31d7ce..ee5d2ed 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -2117,6 +2117,26 @@ unsigned long try_to_free_mem_cgroup_pages(struct mem_cgroup *mem_cont, > > > } > > > #endif > > > > > > +static int all_zone_enough_free_pages(pg_data_t *pgdat) > > > +{ > > > + int i; > > > + > > > + for (i = 0; i < pgdat->nr_zones; i++) { > > > + struct zone *zone = pgdat->node_zones + i; > > > + > > > + if (!populated_zone(zone)) > > > + continue; > > > + > > > + if (zone->all_unreclaimable) > > > + continue; > > > + > > > + if (!zone_watermark_ok(zone, 0, high_wmark_pages(zone) * 8, > > > + 0, 0)) > > > + return 0; > > > + } > > > + return 1; > > > +} > > > + > > > /* is kswapd sleeping prematurely? */ > > > static int sleeping_prematurely(pg_data_t *pgdat, int order, long remaining) > > > { > > > @@ -2355,7 +2375,8 @@ out: > > > * back to sleep. High-order users can still perform direct > > > * reclaim if they wish. > > > */ > > > - if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) > > > + if (sc.nr_reclaimed < SWAP_CLUSTER_MAX || > > > + (order > 0 && all_zone_enough_free_pages(pgdat))) > > > order = sc.order = 0; > > > > Ummm. this doesn't work. this place is processed every 32 pages reclaimed. > > (see below code and comment). Theresore your patch break high order reclaim > > logic. > Yes, this will break high order reclaim, but we need a compromise. > wrongly reclaim pages is more worse. could increase the watermark in > all_zone_enough_free_pages() better? > Hmm.. I guess I haven't catch your mention. you wrote > > > but we do if (sc.nr_reclaimed < SWAP_CLUSTER_MAX) > > > order = sc.order = 0; > > > this means before we set order to 0, we already reclaimed a lot of > > > pages and I wrote it's not a lot. So, I don't understand why you are talking about watermark increasing now. Personally you seems to talk unrelated topic. Can you please elablate your point more? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org