On Wed, Apr 27, 2011 at 9:27 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Wed, 27 Apr 2011 21:24:30 -0700 > Ying Han <yinghan@xxxxxxxxxx> wrote: > >> 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: >> > >> >> >> 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? >> > > Hmm, if kswapd and direc-reclaim uses the same logic, I don't care which > steals memory. But i'm not sure you implementation before seeing patch. > So, please let me postphone answering this. But, considering again, > /proc/vmstat has > == > pgscan_kswapd_dma 0 > pgscan_kswapd_dma32 0 > pgscan_kswapd_normal 0 > pgscan_kswapd_movable 0 > pgscan_direct_dma 0 > pgscan_direct_dma32 0 > pgscan_direct_normal 0 > pgscan_direct_movable 0 > == > > maybe it's ok to have split stats. > > > BTW, ff I add more statistics, I'll add per-node statistics. > Hmm, memory.node_stat is required ? Yes and this will be useful. One of the stats I would like add now is the number of pages allocated on behalf of the memcg per numa node. This is a piece of useful information to evaluate the numa locality correlated to the application performance. I was wondering where to add the stats and memory.stat seems not to be the best fit. If we have memory.node_stat, that would be a good place for those kind of info? --Ying > > >> > >> > >> >> 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. >> > Maybe I answerd this. > > > >> > >> >> 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. >> > Ah, I named them as wmark_scan/wmark_steal for avoiding confusion. > > > 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