On Wed, Aug 31, 2011 at 03:30:25PM +0900, KAMEZAWA Hiroyuki wrote:

On Wed, 31 Aug 2011 08:23:54 +0200
Johannes Weiner [off-list ref] wrote:

quoted

On Wed, Aug 31, 2011 at 08:29:24AM +0900, KAMEZAWA Hiroyuki wrote:

quoted

On Tue, 30 Aug 2011 13:32:21 +0200
Johannes Weiner [off-list ref] wrote:

quoted

On Tue, Aug 30, 2011 at 07:38:39PM +0900, KAMEZAWA Hiroyuki wrote:

quoted

On Tue, 30 Aug 2011 12:17:26 +0200
Johannes Weiner [off-list ref] wrote:

quoted

On Tue, Aug 30, 2011 at 05:56:09PM +0900, KAMEZAWA Hiroyuki wrote:

quoted

On Tue, 30 Aug 2011 10:42:45 +0200
Johannes Weiner [off-list ref] wrote:

quoted

I'm confused. 

If vmscan is scanning in C's LRU,
	(memcg == root) : C_scan_internal ++
	(memcg != root) : C_scan_external ++

Yes.

quoted

Why A_scan_external exists ? It's 0 ?

I think we can never get numbers.

Kswapd/direct reclaim should probably be accounted as A_external,
since A has no limit, so reclaim pressure can not be internal.

hmm, ok. All memory pressure from memcg/system other than the memcg itsef
is all external.

quoted

On the other hand, one could see the amount of physical memory in the
machine as A's limit and account global reclaim as A_internal.

I think the former may be more natural.

That aside, all memcgs should have the same statistics, obviously.
Scripts can easily deal with counters being zero.  If items differ
between cgroups, that would suck a lot.

So, when I improve direct-reclaim path, I need to see score in scan_internal.

Direct reclaim because of the limit or because of global pressure?  I
am going to assume because of the limit because global reclaim is not
yet accounted to memcgs even though their pages are scanned.  Please
correct me if I'm wrong.

        A
       /
      B
     /
    C

If A hits the limit and does direct reclaim in A, B, and C, then the
scans in A get accounted as internal while the scans in B and C get
accounted as external.

How do you think about background-reclaim-per-memcg ?
Should be counted into scan_internal ?

Background reclaim is still triggered by the limit, just that the
condition is 'close to limit' instead of 'reached limit'.

So when per-memcg background reclaim goes off because A is close to
its limit, then it will scan A (internal) and B + C (external).

It's always the same code:

	record_reclaim_stat(culprit, victim, item, delta)

In direct limit reclaim, the culprit is the one hitting its limit.  In
background reclaim, the culprit is the one getting close to its limit.

And then again the accounting is

	culprit == victim -> victim_internal++ (own fault)
	culprit != victim -> victim_external++ (parent's fault)

--
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>