[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8D8BE5.9020902@parallels.com>
Date: Tue, 17 Apr 2012 12:27:33 -0300
From: Glauber Costa <glommer@...allels.com>
To: Tejun Heo <tj@...nel.org>
CC: Johannes Weiner <hannes@...xchg.org>,
Frederic Weisbecker <fweisbec@...il.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Walsh <dwalsh@...hat.com>,
"Daniel P. Berrange" <berrange@...hat.com>,
Li Zefan <lizefan@...wei.com>,
LKML <linux-kernel@...r.kernel.org>,
Cgroups <cgroups@...r.kernel.org>,
Containers <containers@...ts.linux-foundation.org>
Subject: Re: Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter
into memcg)
On 04/17/2012 12:13 PM, Tejun Heo wrote:
> Pretty similar to the plan that I was thinking about.
>
> * Provide both mechanisms from the kernel while implementing new
> features / optimizations with the assumption that there's one
> hierarchy.
I believe the static_keys, that we are already using for the tcp
buffers can play a large role here. They can't save us from the
complexity of still supporting multiple hierarchies in the mean time,
but maybe nothing can.
the only problem with that, is that it is proving itself to be quite
fragile. Because cpusets gets a bunch of function calls with the
cgroup_mutex held from within the cpu hotplug notifier, this creates a
lock dependency between the hotplug lock and cgroup mutex, meaning we
can't call any jump label function patching with the cgroup mutex held.
Neither we seem to be able to defer it to a worker, since it will create
a window of opportunity in which the information presented is inconsistent.
Sigh...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists