[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130729181354.GX715@cmpxchg.org>
Date: Mon, 29 Jul 2013 14:13:54 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...e.cz>,
Linus Torvalds <torvalds@...ux-foundation.org>,
cgroups@...r.kernel.org, containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, kent.overstreet@...il.com,
Li Zefan <lizefan@...wei.com>,
Glauber Costa <glommer@...il.com>
Subject: Re: memcg creates an unkillable task in 3.2-rc2
On Mon, Jul 29, 2013 at 10:03:35AM -0700, Eric W. Biederman wrote:
> Yes. From the looks of the looks of it the cgroup implementation is
> rather badly borked right now, and definitely not up to the standards of
> the other core pieces of the kernel. One of the reasons I was rather
> apalled when systemd started using them. Until the code actually works
> reliably and the races are removed most people's systems would be much
> better off with cgroups compiled out.
>
> A single unified hierarchy is a really nasty idea for the same set of
> reasons. You have to recompile to disable a controller to see if it that
> controller's bugs are what are causing problems on your production
> system. Compiles or even just a reboot is a very heavy hammer to ask
> people to use when they are triaging a problem.
That's not how it works. You can always select which controllers you
want to mount during runtime. Unified hierarchy only means that there
is one cgroup tree for all mounted controllers, rather than every
controller having its own separate cgroup tree.
If you are like most users and currently mount all controllers in the
same directory so that their cgroup trees overlap and appear to be a
single tree, nothing changes for you.
--
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