All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Glauber Costa <glommer@parallels.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
Date: Sun, 7 Apr 2013 14:00:24 +0800	[thread overview]
Message-ID: <51610B78.7080001@huawei.com> (raw)
In-Reply-To: <20130404120049.GI29911@dhcp22.suse.cz>

On 2013/4/4 20:00, Michal Hocko wrote:
> On Wed 03-04-13 17:11:15, Li Zefan wrote:
>> (I'll be off from my office soon, and I won't be responsive in the following
>> 3 days.)
>>
>> I'm working on converting memcg to use cgroup->id, and then we can kill css_id.
>>
>> Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
>> still be alive. This patchset converts memcg to always use css_get/put, so
>> memcg will have the same life cycle as its corresponding cgroup, and then
>> it's always safe for memcg to use cgroup->id.
>>
>> The historical reason that memcg didn't use css_get in some cases, is that
>> cgroup couldn't be removed if there're still css refs. The situation has
>> changed so that rmdir a cgroup will succeed regardless css refs, but won't
>> be freed until css refs goes down to 0.
>>
>> This is an early post, and it's NOT TESTED. I just want to see if the changes
>> are fine in general.
> 
> yes, I like the approach and it looks correct as well (some minor things
> mentioned in the patches). Thanks a lot Li! This will make our lifes much
> easier. The separate ref counting was PITA especially after
> introduction of kmem accounting which made its usage even more trickier.
> 
>> btw, after this patchset I think we don't need to free memcg via RCU, because
>> cgroup is already freed in RCU callback.
> 
> But this depends on changes waiting in for-3.10 branch, right?

What changes? memcg changes or cgroup core changes? I don't think this depends
on anything in cgroup 3.10 branch.

> Anyway, I think we should be safe with the workqueue based releasing as
> well once mem_cgroup_{get,put} are gone, right?
> 

cgroup calls mem_cgroup_css_free() in a work function, so seems memcg doesn't
need to use RCU or workqueue in mem_cgroup_css_free().

--
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: Li Zefan <lizefan@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>,
	Cgroups <cgroups@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Glauber Costa <glommer@parallels.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
Date: Sun, 7 Apr 2013 14:00:24 +0800	[thread overview]
Message-ID: <51610B78.7080001@huawei.com> (raw)
In-Reply-To: <20130404120049.GI29911@dhcp22.suse.cz>

On 2013/4/4 20:00, Michal Hocko wrote:
> On Wed 03-04-13 17:11:15, Li Zefan wrote:
>> (I'll be off from my office soon, and I won't be responsive in the following
>> 3 days.)
>>
>> I'm working on converting memcg to use cgroup->id, and then we can kill css_id.
>>
>> Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
>> still be alive. This patchset converts memcg to always use css_get/put, so
>> memcg will have the same life cycle as its corresponding cgroup, and then
>> it's always safe for memcg to use cgroup->id.
>>
>> The historical reason that memcg didn't use css_get in some cases, is that
>> cgroup couldn't be removed if there're still css refs. The situation has
>> changed so that rmdir a cgroup will succeed regardless css refs, but won't
>> be freed until css refs goes down to 0.
>>
>> This is an early post, and it's NOT TESTED. I just want to see if the changes
>> are fine in general.
> 
> yes, I like the approach and it looks correct as well (some minor things
> mentioned in the patches). Thanks a lot Li! This will make our lifes much
> easier. The separate ref counting was PITA especially after
> introduction of kmem accounting which made its usage even more trickier.
> 
>> btw, after this patchset I think we don't need to free memcg via RCU, because
>> cgroup is already freed in RCU callback.
> 
> But this depends on changes waiting in for-3.10 branch, right?

What changes? memcg changes or cgroup core changes? I don't think this depends
on anything in cgroup 3.10 branch.

> Anyway, I think we should be safe with the workqueue based releasing as
> well once mem_cgroup_{get,put} are gone, right?
> 

cgroup calls mem_cgroup_css_free() in a work function, so seems memcg doesn't
need to use RCU or workqueue in mem_cgroup_css_free().


  reply	other threads:[~2013-04-07  6:00 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03  9:11 [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup Li Zefan
2013-04-03  9:11 ` Li Zefan
2013-04-03  9:11 ` [RFC][PATCH 1/7] memcg: use css_get in sock_update_memcg() Li Zefan
2013-04-03  9:11   ` Li Zefan
2013-04-03 12:58   ` Glauber Costa
2013-04-03 12:58     ` Glauber Costa
2013-04-03 15:29     ` Michal Hocko
2013-04-03 15:29       ` Michal Hocko
     [not found]       ` <20130403152934.GL16471-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-05  8:08         ` Glauber Costa
2013-04-05  8:08           ` Glauber Costa
2013-04-05  8:08           ` Glauber Costa
2013-04-05 13:38           ` Michal Hocko
2013-04-05 13:38             ` Michal Hocko
     [not found]             ` <20130405133815.GE31132-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-05 13:42               ` Glauber Costa
2013-04-05 13:42                 ` Glauber Costa
2013-04-05 13:42                 ` Glauber Costa
     [not found]   ` <515BF249.50607-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-05  5:01     ` Kamezawa Hiroyuki
2013-04-05  5:01       ` Kamezawa Hiroyuki
2013-04-05  5:01       ` Kamezawa Hiroyuki
2013-04-05 13:39     ` Michal Hocko
2013-04-05 13:39       ` Michal Hocko
2013-04-05 13:39       ` Michal Hocko
2013-04-03  9:12 ` [RFC][PATCH 2/7] memcg: don't use mem_cgroup_get() when creating a kmemcg cache Li Zefan
2013-04-03  9:12   ` Li Zefan
2013-04-03 13:05   ` Glauber Costa
2013-04-03 13:05     ` Glauber Costa
2013-04-03 15:31   ` Michal Hocko
2013-04-03 15:31     ` Michal Hocko
     [not found]     ` <20130403153133.GM16471-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-05 10:28       ` Glauber Costa
2013-04-05 10:28         ` Glauber Costa
2013-04-05 10:28         ` Glauber Costa
2013-04-05 13:45         ` Michal Hocko
2013-04-05 13:45           ` Michal Hocko
     [not found]           ` <20130405134557.GG31132-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-07  3:32             ` Li Zefan
2013-04-07  3:32               ` Li Zefan
2013-04-07  3:32               ` Li Zefan
     [not found]   ` <515BF275.5080408-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-05  5:51     ` Kamezawa Hiroyuki
2013-04-05  5:51       ` Kamezawa Hiroyuki
2013-04-05  5:51       ` Kamezawa Hiroyuki
2013-04-05 13:46       ` Michal Hocko
2013-04-05 13:46         ` Michal Hocko
2013-04-03  9:12 ` [RFC][PATCH 3/7] memcg: use css_get/put when charging/uncharging kmem Li Zefan
2013-04-03  9:12   ` Li Zefan
     [not found]   ` <515BF284.7060401-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-04  9:43     ` Michal Hocko
2013-04-04  9:43       ` Michal Hocko
2013-04-04  9:43       ` Michal Hocko
2013-04-05 10:19       ` Glauber Costa
2013-04-05 10:19         ` Glauber Costa
2013-04-05 10:19         ` Glauber Costa
     [not found]         ` <515EA532.4050706-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-04-05 13:48           ` Michal Hocko
2013-04-05 13:48             ` Michal Hocko
2013-04-05 13:48             ` Michal Hocko
2013-04-05 10:19     ` Glauber Costa
2013-04-05 10:19       ` Glauber Costa
2013-04-05 10:19       ` Glauber Costa
2013-04-03  9:12 ` [RFC][PATCH 4/7] memcg: use css_get/put for swap memcg Li Zefan
2013-04-03  9:12   ` Li Zefan
2013-04-04 11:25   ` Michal Hocko
2013-04-04 11:25     ` Michal Hocko
2013-04-05  5:56   ` Kamezawa Hiroyuki
2013-04-05  5:56     ` Kamezawa Hiroyuki
2013-04-03  9:13 ` [RFC][PATCH 5/7] cgroup: make sure parent won't be destroyed before its children Li Zefan
2013-04-03  9:13   ` Li Zefan
     [not found]   ` <515BF2A4.1070703-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-04 11:37     ` Michal Hocko
2013-04-04 11:37       ` Michal Hocko
2013-04-04 11:37       ` Michal Hocko
     [not found]       ` <20130404113750.GH29911-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-04 13:53         ` Tejun Heo
2013-04-04 13:53           ` Tejun Heo
2013-04-04 13:53           ` Tejun Heo
2013-04-04 15:20           ` Michal Hocko
2013-04-04 15:20             ` Michal Hocko
     [not found]             ` <20130404152028.GK29911-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-04-04 15:22               ` Tejun Heo
2013-04-04 15:22                 ` Tejun Heo
2013-04-04 15:22                 ` Tejun Heo
2013-04-04 15:30                 ` Michal Hocko
2013-04-04 15:30                   ` Michal Hocko
     [not found]                 ` <20130404152213.GL9425-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-04-05  8:10                   ` Glauber Costa
2013-04-05  8:10                     ` Glauber Costa
2013-04-05  8:10                     ` Glauber Costa
2013-04-04 15:31   ` Michal Hocko
2013-04-04 15:31     ` Michal Hocko
2013-04-05  5:58   ` Kamezawa Hiroyuki
2013-04-05  5:58     ` Kamezawa Hiroyuki
2013-04-03  9:13 ` [RFC][PATCH 6/7] memcg: don't need to get a reference to the parent Li Zefan
2013-04-03  9:13   ` Li Zefan
     [not found]   ` <515BF2B1.9060909-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-04 15:34     ` Michal Hocko
2013-04-04 15:34       ` Michal Hocko
2013-04-04 15:34       ` Michal Hocko
2013-04-05  9:22     ` Kamezawa Hiroyuki
2013-04-05  9:22       ` Kamezawa Hiroyuki
2013-04-05  9:22       ` Kamezawa Hiroyuki
2013-04-03  9:14 ` [RFC][PATCH 7/7] memcg: kill memcg refcnt Li Zefan
2013-04-03  9:14   ` Li Zefan
     [not found]   ` <515BF2E3.4000605-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-04 15:35     ` Michal Hocko
2013-04-04 15:35       ` Michal Hocko
2013-04-04 15:35       ` Michal Hocko
2013-04-05  9:24     ` Kamezawa Hiroyuki
2013-04-05  9:24       ` Kamezawa Hiroyuki
2013-04-05  9:24       ` Kamezawa Hiroyuki
2013-04-03  9:19 ` [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup Glauber Costa
2013-04-03  9:19   ` Glauber Costa
     [not found] ` <515BF233.6070308-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-03 21:43   ` Tejun Heo
2013-04-03 21:43     ` Tejun Heo
2013-04-03 21:43     ` Tejun Heo
2013-04-04 12:00   ` Michal Hocko
2013-04-04 12:00     ` Michal Hocko
2013-04-04 12:00     ` Michal Hocko
2013-04-07  6:00     ` Li Zefan [this message]
2013-04-07  6:00       ` Li Zefan
     [not found]       ` <51610B78.7080001-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-07 20:21         ` Michal Hocko
2013-04-07 20:21           ` Michal Hocko
2013-04-07 20:21           ` Michal Hocko
2013-04-07  8:44   ` Li Zefan
2013-04-07  8:44     ` Li Zefan
2013-04-07  8:44     ` Li Zefan
2013-04-07 19:51     ` Michal Hocko
2013-04-07 19:51       ` Michal Hocko
     [not found]     ` <516131D7.8030004-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-04-08  7:18       ` Glauber Costa
2013-04-08  7:18         ` Glauber Costa
2013-04-08  7:18         ` Glauber Costa

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=51610B78.7080001@huawei.com \
    --to=lizefan@huawei.com \
    --cc=cgroups@vger.kernel.org \
    --cc=glommer@parallels.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=tj@kernel.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.