From: Glauber Costa <glommer@gmail.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
cgroups@vger.kernel.org, Glauber Costa <glommer@openvz.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH] memcg: make cache index determination more robust
Date: Fri, 14 Jun 2013 15:01:45 +0400 [thread overview]
Message-ID: <20130614110145.GB4292@localhost.localdomain> (raw)
In-Reply-To: <20130613163849.GL23070@dhcp22.suse.cz>
On Thu, Jun 13, 2013 at 06:38:49PM +0200, Michal Hocko wrote:
> On Wed 12-06-13 16:43:28, Glauber Costa wrote:
> > I caught myself doing something like the following outside memcg core:
> >
> > memcg_id = -1;
> > if (memcg && memcg_kmem_is_active(memcg))
> > memcg_id = memcg_cache_id(memcg);
> >
> > to be able to handle all possible memcgs in a sane manner. In particular, the
> > root cache will have kmemcg_id = -1 (just because we don't call memcg_kmem_init
> > to the root cache since it is not limitable). We have always coped with that by
> > making sure we sanitize which cache is passed to memcg_cache_id. Although this
> > example is given for root, what we really need to know is whether or not a
> > cache is kmem active.
> >
> > But outside the memcg core testing for root, for instance, is not trivial since
> > we don't export mem_cgroup_is_root. I ended up realizing that this tests really
> > belong inside memcg_cache_id. This patch moves the tests inside memcg_cache_id
> > and make sure it always return a meaningful value.
>
> This is quite a mess, to be honest. Some callers test/require
> memcg_can_account_kmem others !p->is_root_cache. Can we have that
> unified, please?
>
> Also the return value of this function is used mostly as an index to
> memcg_params->memcg_caches array so returning -1 sounds like a bad idea.
> Few other cases use it as a real id. Maybe we need to split this up.
>
> Pulling the check inside the function is OK but can we settle with a
> common pattern here, pretty please?
>
We have been through the array index discussion before. It is used as an array index
only in contexts where we are absolutely sure we are dealing with a memcg that is kmem
limited. Those are usually contexts in which in case it is not, we would have to BUG
anyway.
If you prefer, though, that we always BUG on id == -1 in those scenarios, for consistency,
this is understandable and I will prepare a patch for this.
--
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>
next prev parent reply other threads:[~2013-06-14 11:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 20:43 [PATCH] memcg: make cache index determination more robust Glauber Costa
2013-06-13 16:38 ` Michal Hocko
2013-06-14 11:01 ` Glauber Costa [this message]
2013-06-14 13:53 ` Michal Hocko
2013-06-14 11:24 ` Glauber Costa
2013-06-14 13:56 ` Michal Hocko
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=20130614110145.GB4292@localhost.localdomain \
--to=glommer@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=glommer@openvz.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).