All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov@parallels.com>
To: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Dave Chinner <david@fromorbit.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm v2 3/7] cgroup: release css->id after css_free
Date: Mon, 19 Jan 2015 18:18:54 +0300	[thread overview]
Message-ID: <20150119151854.GA28598@esperanza> (raw)
In-Reply-To: <20150119143001.GH8140@htj.dyndns.org>

Hi Tejun,

On Mon, Jan 19, 2015 at 09:30:01AM -0500, Tejun Heo wrote:
> On Mon, Jan 19, 2015 at 02:23:21PM +0300, Vladimir Davydov wrote:
> > Currently, we release css->id in css_release_work_fn, right before
> > calling css_free callback, so that when css_free is called, the id may
> > have already been reused for a new cgroup.
> > 
> > I am going to use css->id to create unique names for per memcg kmem
> > caches. Since kmem caches are destroyed only on css_free, I need css->id
> > to be freed after css_free was called to avoid name clashes. This patch
> > therefore moves css->id removal to css_free_work_fn. To prevent
> > css_from_id from returning a pointer to a stale css, it makes
> > css_release_work_fn replace the css ptr at css_idr:css->id with NULL.
> 
> I think it'd be better if you create a separate id for this purpose.
> The requirement is pretty unusual and likely contradictory with other
> usages.

Could you please elaborate this? I mean, what problems do you think can
arise if we release css->id a little bit (one grace period) later?

Of course, I can introduce yet another id per memcg, but I think we have
css->id to avoid code duplication in controllers.

Thanks,
Vladimir

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

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Davydov <vdavydov@parallels.com>
To: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Dave Chinner <david@fromorbit.com>,
	Al Viro <viro@zeniv.linux.org.uk>, <linux-mm@kvack.org>,
	<cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -mm v2 3/7] cgroup: release css->id after css_free
Date: Mon, 19 Jan 2015 18:18:54 +0300	[thread overview]
Message-ID: <20150119151854.GA28598@esperanza> (raw)
In-Reply-To: <20150119143001.GH8140@htj.dyndns.org>

Hi Tejun,

On Mon, Jan 19, 2015 at 09:30:01AM -0500, Tejun Heo wrote:
> On Mon, Jan 19, 2015 at 02:23:21PM +0300, Vladimir Davydov wrote:
> > Currently, we release css->id in css_release_work_fn, right before
> > calling css_free callback, so that when css_free is called, the id may
> > have already been reused for a new cgroup.
> > 
> > I am going to use css->id to create unique names for per memcg kmem
> > caches. Since kmem caches are destroyed only on css_free, I need css->id
> > to be freed after css_free was called to avoid name clashes. This patch
> > therefore moves css->id removal to css_free_work_fn. To prevent
> > css_from_id from returning a pointer to a stale css, it makes
> > css_release_work_fn replace the css ptr at css_idr:css->id with NULL.
> 
> I think it'd be better if you create a separate id for this purpose.
> The requirement is pretty unusual and likely contradictory with other
> usages.

Could you please elaborate this? I mean, what problems do you think can
arise if we release css->id a little bit (one grace period) later?

Of course, I can introduce yet another id per memcg, but I think we have
css->id to avoid code duplication in controllers.

Thanks,
Vladimir

  reply	other threads:[~2015-01-19 15:18 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19 11:23 [PATCH -mm v2 0/7] memcg: release kmemcg_id on css offline Vladimir Davydov
2015-01-19 11:23 ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 1/7] slab: embed memcg_cache_params to kmem_cache Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 2/7] slab: link memcg caches of the same kind into a list Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 3/7] cgroup: release css->id after css_free Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 14:30   ` Tejun Heo
2015-01-19 14:30     ` Tejun Heo
2015-01-19 15:18     ` Vladimir Davydov [this message]
2015-01-19 15:18       ` Vladimir Davydov
2015-01-19 15:42       ` Tejun Heo
2015-01-19 15:42         ` Tejun Heo
2015-01-19 15:42         ` Tejun Heo
2015-01-19 11:23 ` [PATCH -mm v2 4/7] slab: use css id for naming per memcg caches Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 5/7] memcg: free memcg_caches slot on css offline Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 6/7] list_lru: add helpers to isolate items Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov
2015-01-19 11:23 ` [PATCH -mm v2 7/7] memcg: reparent list_lrus and free kmemcg_id on css offline Vladimir Davydov
2015-01-19 11:23   ` Vladimir Davydov

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=20150119151854.GA28598@esperanza \
    --to=vdavydov@parallels.com \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@linux.com \
    --cc=david@fromorbit.com \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.