Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith <umgwanakikbuti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Sun, 2015-10-25 at 11:18 +0900, Tejun Heo wrote:
> Hello, Mike.
> 
> On Sat, Oct 24, 2015 at 06:36:07AM +0200, Mike Galbraith wrote:
> > On Sat, 2015-10-24 at 07:21 +0900, Tejun Heo wrote:
> > 
> > > It'd be a step back in usability only for users who have been using
> > > cgroups in fringing ways which can't be justified for ratification and
> > > we do want to actively filter those out.
> > 
> > Of all the cgroup signal currently in existence, seems the Google signal
> > has to have the most volume under the curve by a mile.  If you were to
> > filter that signal out, what remained would be a flat line of noise.
> 
> This is a weird direction to take the discussion, but let me provide a
> counter argument.

I don't think it's weird, it's just a thought wrt where pigeon holing
could lead:  If you filter out current users who do so in a manner you
consider to be in some way odd, when all the filtering is done, you may
find that you've filtered out the vast majority of current deployment.

> Google sure is an important user of the kernel and likely the most
> extensive user of cgroup.  At the same time, its kernel efforts are
> largely in service of a few very big internal customers which are in
> control of large part of the entire software stack.  The things that
> are important for general audience of the kernel in the long term
> don't necessarily coincide with what such efforts need or want.

I'm not at all sure of this, but I suspect that SUSE's gigabuck size
cgroup power user will land in the same "fringe" pigeon hole.  If so,
that would be another sizeable dent in volume.

My point is that these power users likely _are_ your general audience.
 
> I'd even venture to say as much as the inputs coming out of google are
> interesting and important, they're also a lot more prone to lock-in
> effects to short term solutions and status-quo given their priorities.
> This is not to denigrate google's kernel efforts but just to
> counter-balance "it's google" as a shortcut for proper technical
> discussions.
> 
> There are good reasons why cgroup is the design disaster as it is now
> and chasing each usage scenario and hack which provides the least
> immediate resistance without paying the effort to extract the actual
> requirements and common solutions is an important one.  It is critical
> to provide back-pressure for long-term thinking and solutions;
> otherwise, we're bound to repeat the errors and end up with something
> which everyone loves to hate.
> 
> We definitely need to weigh the inputs from heavy users but also need
> to discern the actual problems which need to be solved from the
> specific mechanisms chosen to solve them.  Let's please keep the
> discussions technical.

Sure, it was just a thought wrt "actively filter those out" and who all
"those" may end up being.

	-Mike