On Wed, Apr 27, 2011 at 8:57 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > 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. Ok, thanks for the clarification. The patch i am working now to be more specific is to add the soft_limit hierarchical reclaim on the global direct reclaim. I am adding similar stats to monitor the soft_steal, but i split-off the soft_steal from global direct reclaim and global background reclaim. I am wondering isn't that give us more visibility of the reclaim path? > >> The same for the limit_steal/scan. > > limit has only direct reclaim, now. And this is independent from any > soft limit works. agree. > >> 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. good point. thanks > > >> 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. the same question above, why we don't want to have better visibility of where we triggered the soft_limit reclaim and how much has been done on behalf of each. > >> 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 ? you can ignore those four stats. They are part of the per-memcg-kswapd patchset, and i guess you might have similar patch for that purpose. > > 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 for the heads up ~ --Ying > > 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