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

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Wed, 27 Apr 2011 21:24:30 -0700
Ying Han <yinghan@google.com> wrote:

> On Wed, Apr 27, 2011 at 8:57 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 27 Apr 2011 20:43:58 -0700
> > Ying Han <yinghan@google.com> 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
> > A 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@kvack.org.  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@kvack.org"> email@kvack.org </a>