Re: Fw: [PATCH] memcg: add reclaim statistics accounting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 27 Apr 2011 20:43:58 -0700
Ying Han <yinghan@xxxxxxxxxx> wrote:

> On Wed, Apr 27, 2011 at 8:16 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > sorry, I had wrong TO:...
> >
> > Begin forwarded message:
> >
> > Date: Thu, 28 Apr 2011 12:02:34 +0900
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
> > To: linux-mm@xxxxxxxxxxxxxxx
> > Cc: "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "nishimura@xxxxxxxxxxxxxxxxx" <nishimura@xxxxxxxxxxxxxxxxx>, "balbir@xxxxxxxxxxxxxxxxxx" <balbir@xxxxxxxxxxxxxxxxxx>, Ying Han <yinghan@xxxxxxxxxx>, "akpm@xxxxxxxxxxxxxxxxxxxx" <akpm@xxxxxxxxxxxxxxxxxxxx>
> > Subject: [PATCH] memcg: add reclaim statistics accounting
> >
> >
> >
> > Now, memory cgroup provides poor reclaim statistics per memcg. This
> > patch adds statistics for direct/soft reclaim as the number of
> > pages scans, the number of page freed by reclaim, the nanoseconds of
> > latency at reclaim.
> >
> > It's good to add statistics before we modify memcg/global reclaim, largely.
> > This patch refactors current soft limit status and add an unified update logic.
> >
> > For example, After #cat 195Mfile > /dev/null under 100M limit.
> > Â Â Â Â# cat /cgroup/memory/A/memory.stat
> > Â Â Â Â....
> > Â Â Â Âlimit_freed 24592
> 
> why not "limit_steal" ?
> 

It's not "stealed". Freed by itself.
pages reclaimed by soft-limit is stealed because of global memory pressure.
I don't like the name "steal" but I can't change it because of API breakage.


> > Â Â Â Âsoft_steal 0
> > Â Â Â Âlimit_scan 43974
> > Â Â Â Âsoft_scan 0
> > Â Â Â Âlimit_latency 133837417
> >
> > nearly 96M caches are freed. scanned twice. used 133ms.
> 
> Does it make sense to split up the soft_steal/scan for bg reclaim and
> direct reclaim? 

Please clarify what you're talking about before asking. Maybe you want to say
"I'm now working for supporting softlimit in direct reclaim path. So, does
 it make sense to account direct/kswapd works in statistics ?"

I think bg/direct reclaim is not required to be splitted.

> The same for the limit_steal/scan. 

limit has only direct reclaim, now. And this is independent from any
soft limit works.

> I am now testing
> the patch to add the soft_limit reclaim on global ttfp, and i already
> have the patch to add the following:
> 
> kswapd_soft_steal 0
> kswapd_soft_scan 0

please don't change the name of _used_ statisitcs.


> direct_soft_steal 0
> direct_soft_scan 0

Maybe these are new ones added by your work. But should be merged to
soft_steal/soft_scan.

> kswapd_steal 0
> pg_pgsteal 0
> kswapd_pgscan 0
> pg_scan 0
> 

Maybe this indicates reclaimed-by-other-tasks-than-this-memcg. Right ?
Maybe good for checking isolation of memcg, hmm, can these be accounted
in scalable way ?

BTW, my office will be closed for a week because of holidays. So, I'll not make
responce tomorrow. please CC kamezawa.hiroyuki@xxxxxxxxx if you need.
I may read e-mails.

Thanks,
-Kame



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]