All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: nishimura@mxp.nes.nec.co.jp,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 10/10] memcg: add commentary
Date: Wed, 30 Sep 2009 13:36:18 +0900	[thread overview]
Message-ID: <20090930133618.1055e551.nishimura@mxp.nes.nec.co.jp> (raw)
In-Reply-To: <20090930114105.66bdcd7a.kamezawa.hiroyu@jp.fujitsu.com>

> > > + * we never select a memcg which has no memory usage on this zone.
> > > + */
> > I'm sorry if I misunderstand about softlimit implementation, what prevents
> > a memcg which has no memory usage on this zone from being selected ?
> > IIUC, mz->usage_in_excess has a value calculated from res_counter_soft_limit_excess(),
> > which doesn't take account of zone but only calculates "usage - soft_limit".
> > 
> right. But the point is that if memcg has _no_ pages in the zone, memcg is
> not on RB-tree. So, Hmm, How about this ?
Thank you for your clarification.

> ==
> Because this soft-limit tree is maintained per zone, if memcg has little usage on
> this zone, we can expect such memcg won't be found on this per-zone RB-tree.
> ==
> 
I think "never" above is exaggeration a bit, but otherwise it looks good for me.

> I wonder there are something should be improved on this tree management.
I agree.
But I think it would be enough for now to leave it in TODO-list.


Thanks,
Daisuke Nishimura.

> Maybe we should add some per-zone check around here.
> ==
> >                 __mem_cgroup_remove_exceeded(mz->mem, mz, mctz);
> >                 excess = res_counter_soft_limit_excess(&mz->mem->res);
> >                 /*
> >                  * One school of thought says that we should not add
> >                  * back the node to the tree if reclaim returns 0.
> >                  * But our reclaim could return 0, simply because due
> >                  * to priority we are exposing a smaller subset of
> >                  * memory to reclaim from. Consider this as a longer
> >                  * term TODO.
> >                  */
> >                 /* If excess == 0, no tree ops */
> >                 __mem_cgroup_insert_exceeded(mz->mem, mz, mctz, excess);
> >                 spin_unlock(&mctz->lock);
> ==
> Its cost will not be high.
> 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2009-09-30  4:39 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-25  8:17 [RFC][PATCH 0/10] memcg clean up and some fixes for softlimit (Sep25) KAMEZAWA Hiroyuki
2009-09-25  8:18 ` [RFC][PATCH 1/10] memcg : modifications for softlimit uncharge KAMEZAWA Hiroyuki
2009-09-25  8:20 ` [RFC][PATCH 2/10] memcg : clean up in softlimit charge KAMEZAWA Hiroyuki
2009-09-25  8:21 ` [RFC][PATCH 3/10] memcg: reorganize memcontrol.c KAMEZAWA Hiroyuki
2009-09-25  8:22 ` [RFC][PATCH 4/10] memcg: add memcg charge cancel KAMEZAWA Hiroyuki
2009-09-25  8:24 ` [RFC][PATCH 5/10] memcg: clean up percpu statistics access KAMEZAWA Hiroyuki
2009-09-25  8:25 ` [RFC][PATCH 6/10] memcg: remove unsued macros KAMEZAWA Hiroyuki
2009-09-25  8:25 ` [RFC][PATCH 0/10] memcg clean up and some fixes for softlimit (Sep25) Balbir Singh
2009-09-25  8:27 ` [RFC][PATCH 7/10] memcg: replace cont with cgroup KAMEZAWA Hiroyuki
2009-09-25  8:28 ` [RFC][PATCH 8/10] memcg: clean up charge/uncharge anon KAMEZAWA Hiroyuki
2009-09-29  0:24   ` Daisuke Nishimura
2009-09-29  1:26     ` KAMEZAWA Hiroyuki
2009-09-29  2:18       ` Daisuke Nishimura
2009-09-29  3:03         ` Daisuke Nishimura
2009-09-29  3:14           ` KAMEZAWA Hiroyuki
2009-09-25  8:29 ` [RFC][PATCH 9/10] memcg: clean up perzone stat KAMEZAWA Hiroyuki
2009-09-25  8:30 ` [RFC][PATCH 10/10] memcg: add commentary KAMEZAWA Hiroyuki
2009-09-30  2:21   ` Daisuke Nishimura
2009-09-30  2:41     ` KAMEZAWA Hiroyuki
2009-09-30  4:36       ` Daisuke Nishimura [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=20090930133618.1055e551.nishimura@mxp.nes.nec.co.jp \
    --to=nishimura@mxp.nes.nec.co.jp \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.