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 ? > > > > > >> 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>