[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080220181447.6444.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date: Wed, 20 Feb 2008 18:24:19 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: "minchan Kim" <barrioskmc@...il.com>
Cc: kosaki.motohiro@...fujitsu.com,
"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>,
"Balbir Singh" <balbir@...ux.vnet.ibm.com>,
"Rik van Riel" <riel@...hat.com>,
"Lee Schermerhorn" <Lee.Schermerhorn@...com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] the proposal of improve page reclaim by throttle
Hi Kim-san
Do you adjust hackbench parameter?
my parameter adjust my test machine(8GB mem),
if unchanged, maybe doesn't works it because lack memory.
> I am a many interested in your patch. so I want to test it with exact
> same method as you did.
> I will test it in embedded environment(ARM 920T, 32M ram) and my
> desktop machine.(Core2Duo 2.2G, 2G ram)
Hm
I don't have embedded test machine.
but I can desktop.
I will test it about weekend.
if you don't mind, could you please send me .config file
and tell me your test kernel version?
Thanks, interesting report.
> I guess this patch won't be efficient in embedded environment.
> Since many embedded board just have one processor and don't have any
> swap device.
reclaim conflict rarely happened on UP.
thus, my patch expect no improvement.
but (of course) I will fix regression.
> So, How do I evaluate following field as you did ?
>
> * elapse (what do you mean it ??)
> * major fault
/usr/bin/time command output that.
> * max parallel reclaim tasks:
> * max consumption time of
> try_to_free_pages():
sorry, I inserted debug code to my patch at that time.
--
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/
Powered by blists - more mailing lists