linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Ying Han <yinghan@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Fw: [PATCH] memcg: add reclaim statistics accounting
Date: Fri, 29 Apr 2011 08:26:47 +0200	[thread overview]
Message-ID: <20110429062647.GN12437@cmpxchg.org> (raw)
In-Reply-To: <BANLkTikJxWmF+8P3-pGeyECaDoV01v77Pg@mail.gmail.com>

On Thu, Apr 28, 2011 at 10:46:07AM -0700, Ying Han wrote:
> On Thu, Apr 28, 2011 at 5:36 AM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> > 1. Limit-triggered direct reclaim
> >
> > The memory cgroup hits its limit and the task does direct reclaim from
> > its own memcg.  We probably want statistics for this separately from
> > background reclaim to see how successful background reclaim is, the
> > same reason we have this separation in the global vmstat as well.
> >
> >        pgscan_direct_limit
> >        pgfree_direct_limit
> 
> Ack.
> >
> > 2. Limit-triggered background reclaim
> >
> > This is the watermark-based asynchroneous reclaim that is currently in
> > discussion.  It's triggered by the memcg breaching its watermark,
> > which is relative to its hard-limit.  I named it kswapd because I
> > still think kswapd should do this job, but it is all open for
> > discussion, obviously.  Treat it as meaning 'background' or
> > 'asynchroneous'.
> >
> >        pgscan_kswapd_limit
> >        pgfree_kswapd_limit
> Ack.
> 
> To clarify, the 1 and 2 only count the reclaim which is due to the
> pressure from the memcg itself.

Yes, limit-triggered implies that.  If you have reclaim going on in a
memcg that is unrelated to the limit, the pressure must be external.

> > 3. Hierarchy-triggered direct reclaim
> >
> > A condition outside the memcg leads to a task directly reclaiming from
> > this memcg.  This could be global memory pressure for example, but
> > also a parent cgroup hitting its limit.  It's probably helpful to
> > assume global memory pressure meaning that the root cgroup hit its
> > limit, conceptually.  We don't have that yet, but this could be the
> > direct softlimit reclaim Ying mentioned above.
> >
> >        pgscan_direct_hierarchy
> >        pgsteal_direct_hierarchy
> 
> For this one, it could be global direct reclaim doing softlimit
> pushback or hierarchical reclaim
> due to the parent hit its hardlimit. It would be nice if we can
> separate them up?

Short-answer: you are able to differentiate between the two by looking
at the memcg.  If the parent is the root cgroup, you know its direct
softlimit reclaim.

Long-answer:

In the paragraph of 3., I suggested that they are conceptually the
same.  If you observe hierarchical pressure on a memcg, you know that
one of the ancestors is in trouble and go up the chain to find which
one has internal pressure.  If the troubled ancestor turns out to be
the root cgroup, you know that it's a physical memory shortness, as
its ownly limit is physical memory.

It can all be described with the memcg-native concept of hierarchy and
the specialness of the root cgroup.

	Hannes

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

      reply	other threads:[~2011-04-29  6:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-28  3:16 KAMEZAWA Hiroyuki
2011-04-28  3:43 ` Ying Han
2011-04-28  3:57   ` KAMEZAWA Hiroyuki
2011-04-28  4:24     ` Ying Han
2011-04-28  4:27       ` KAMEZAWA Hiroyuki
2011-04-28  4:40         ` Ying Han
2011-04-28  7:02           ` KAMEZAWA Hiroyuki
2011-04-28  9:01   ` KAMEZAWA Hiroyuki
2011-04-28 12:36     ` Johannes Weiner
2011-04-28 17:46       ` Ying Han
2011-04-29  6:26         ` Johannes Weiner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110429062647.GN12437@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=yinghan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox