[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1460182603.3765.155.camel@gmail.com>
Date: Sat, 09 Apr 2016 08:16:43 +0200
From: Mike Galbraith <umgwanakikbuti@...il.com>
To: Tejun Heo <tj@...nel.org>, Peter Zijlstra <peterz@...radead.org>
Cc: Johannes Weiner <hannes@...xchg.org>,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
mingo@...hat.com, lizefan@...wei.com, pjt@...gle.com,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
linux-api@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource
group and PRIO_RGRP
On Fri, 2016-04-08 at 16:11 -0400, Tejun Heo wrote:
> > That's just plain broken... That is not how a proportional weight based
> > hierarchical controller works.
>
> That's a strong statement. When the hierarchy is composed of
> equivalent objects as in CPU, not distinguishing internal and leaf
> nodes would be a more natural way to organize; however...
You almost said it yourself, you want to make the natural organization
of cpu, cpuacct and cpuset controllers a prohibited organization.
There is no "however..." that can possibly justify that. It's akin to
mandating: henceforth "horse" shall be spelled "cow", riders thereof
shall teach their "cow" the proper enunciation of "moo". It's silly.
Like it or not, these controllers have thread encoded in their DNA,
it's an integral part of what they are, and how real users in the real
world use them. No rationalization will change that cold hard fact.
Make an "Aunt Tilly" button for those incapable of comprehending the
complexities if you will, but please don't make cgroups so rigid and
idiot proof that only idiots (hi system thing) can use it.
-Mike
Powered by blists - more mailing lists