From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: lizefan@huawei.com, paul@paulmenage.org,
containers@lists.linux-foundation.org, cgroups@vger.kernel.org,
peterz@infradead.org, mhocko@suse.cz, bsingharora@gmail.com,
hannes@cmpxchg.org, kamezawa.hiroyu@jp.fujitsu.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHSET cgroup/for-3.8] cpuset: decouple cpuset locking from cgroup core
Date: Thu, 29 Nov 2012 06:36:50 -0800 [thread overview]
Message-ID: <20121129143650.GE24683@htj.dyndns.org> (raw)
In-Reply-To: <20121129142646.GD24683@htj.dyndns.org>
On Thu, Nov 29, 2012 at 06:26:46AM -0800, Tejun Heo wrote:
> > What I'll try to do, is to come with another specialized lock in cgroup
> > just for this case. So after taking the cgroup lock, we would also take
> > an extra lock if we are adding another entry - be it task or children -
> > to the cgroup.
>
> No, please don't do that. Just don't invoke cgroup operation inside
> any subsystem lock.
To add a bit, you won't be solving any problem by adding more locks
here. cpuset wants to initiate task cgroup migration. It doesn't
matter how many locks cgroup uses internally. You'll have to grab
them all anyway to do that. It's not a problem caused by granularity
of cgroup_lock at all, so there just isn't any logic in dividing locks
for this. So, again, please don't go that direction. What we need to
do is isolating subsystem locking and implementation from cgroup
internals, not complicating cgroup internals even more, and now we
have good enoug API to achieve such isolation.
Thanks.
--
tejun
--
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:[~2012-11-29 14:36 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 21:34 [PATCHSET cgroup/for-3.8] cpuset: decouple cpuset locking from cgroup core Tejun Heo
2012-11-28 21:34 ` [PATCH 01/13] cpuset: remove unused cpuset_unlock() Tejun Heo
2012-11-28 21:34 ` [PATCH 02/13] cpuset: remove fast exit path from remove_tasks_in_empty_cpuset() Tejun Heo
2012-11-28 21:34 ` [PATCH 03/13] cpuset: introduce ->css_on/offline() Tejun Heo
2012-11-28 21:34 ` [PATCH 04/13] cpuset: introduce CS_ONLINE Tejun Heo
2012-11-28 21:34 ` [PATCH 05/13] cpuset: introduce cpuset_for_each_child() Tejun Heo
2012-11-28 21:34 ` [PATCH 06/13] cpuset: cleanup cpuset[_can]_attach() Tejun Heo
2012-12-26 10:20 ` Li Zefan
2012-12-26 12:04 ` Tejun Heo
2013-01-02 4:42 ` Rusty Russell
2013-01-02 15:34 ` Tejun Heo
2013-01-03 0:47 ` Rusty Russell
2013-01-03 2:29 ` Tejun Heo
2013-01-06 23:28 ` Rusty Russell
2012-11-28 21:34 ` [PATCH 07/13] cpuset: drop async_rebuild_sched_domains() Tejun Heo
2012-11-28 21:34 ` [PATCH 08/13] cpuset: reorganize CPU / memory hotplug handling Tejun Heo
2012-11-28 21:34 ` [PATCH 09/13] cpuset: don't nest cgroup_mutex inside get_online_cpus() Tejun Heo
2012-11-28 21:34 ` [PATCH 10/13] cpuset: make CPU / memory hotplug propagation asynchronous Tejun Heo
2012-11-28 21:34 ` [PATCH 11/13] cpuset: pin down cpus and mems while a task is being attached Tejun Heo
2012-11-28 21:34 ` [PATCH 12/13] cpuset: schedule hotplug propagation from cpuset_attach() if the cpuset is empty Tejun Heo
2012-11-28 21:34 ` [PATCH 13/13] cpuset: replace cgroup_mutex locking with cpuset internal locking Tejun Heo
2012-11-29 11:14 ` [PATCHSET cgroup/for-3.8] cpuset: decouple cpuset locking from cgroup core Glauber Costa
2012-11-29 14:26 ` Tejun Heo
2012-11-29 14:36 ` Tejun Heo [this message]
2012-11-30 3:21 ` Kamezawa Hiroyuki
2012-11-30 8:33 ` Michal Hocko
2012-11-30 9:00 ` Glauber Costa
2012-11-30 9:24 ` Michal Hocko
2012-11-30 9:33 ` Glauber Costa
2012-11-30 9:42 ` Glauber Costa
2012-11-30 9:49 ` Michal Hocko
2012-11-30 10:00 ` Glauber Costa
2012-11-30 14:59 ` Tejun Heo
2012-11-30 15:09 ` Glauber Costa
2012-12-03 15:22 ` Michal Hocko
2012-12-03 16:53 ` Tejun Heo
2012-12-06 6:25 ` Li Zefan
2012-12-06 13:09 ` Michal Hocko
2012-12-06 16:54 ` Tejun Heo
2012-12-26 10:51 ` Li Zefan
2013-01-02 8:53 ` Michal Hocko
2013-01-02 15:36 ` Tejun Heo
2013-01-02 16:02 ` Michal Hocko
2013-01-03 22:20 ` Tejun Heo
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=20121129143650.GE24683@htj.dyndns.org \
--to=tj@kernel.org \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.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=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=paul@paulmenage.org \
--cc=peterz@infradead.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 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).