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

[Ying Han <yinghan@google.com>]

On Wed, Apr 27, 2011 at 9:27 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 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
>> >  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@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>