From: Tejun Heo <tj@kernel.org>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Paul Turner <pjt@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
lizefan@huawei.com, cgroups <cgroups@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-team <kernel-team@fb.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Date: Sun, 25 Oct 2015 11:18:29 +0900 [thread overview]
Message-ID: <20151025021829.GA15471@mtj.duckdns.org> (raw)
In-Reply-To: <1445661367.3218.62.camel@gmail.com>
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.
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'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. That's the best way to reach a viable
long-term solution which can benefit a lot wider audience in the long
term. Even though that might not be the path of least immediate
resistance, I believe that google will be an eventual beneficiary too.
Thanks.
--
tejun
next prev parent reply other threads:[~2015-10-25 2:18 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-03 22:41 [PATCHSET sched,cgroup] " Tejun Heo
2015-08-03 22:41 ` [PATCH 1/3] cgroup: define controller file conventions Tejun Heo
2015-08-04 8:42 ` Peter Zijlstra
2015-08-04 14:51 ` Tejun Heo
2015-08-04 8:48 ` Peter Zijlstra
2015-08-04 14:53 ` Tejun Heo
2015-08-04 19:31 ` [PATCH v2 " Tejun Heo
2015-08-05 0:39 ` Kamezawa Hiroyuki
2015-08-05 7:47 ` Michal Hocko
2015-08-06 2:30 ` Kamezawa Hiroyuki
2015-08-07 18:17 ` Michal Hocko
2015-08-17 22:04 ` Johannes Weiner
2015-08-17 21:34 ` Johannes Weiner
2015-08-03 22:41 ` [PATCH 2/3] sched: Misc preps for cgroup unified hierarchy interface Tejun Heo
2015-08-03 22:41 ` [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Tejun Heo
2015-08-04 9:07 ` Peter Zijlstra
2015-08-04 15:10 ` Tejun Heo
2015-08-05 9:10 ` Peter Zijlstra
2015-08-05 14:31 ` Tejun Heo
2015-08-17 20:35 ` Tejun Heo
[not found] ` <CAPM31RJTf0v=2v90kN6-HM9xUGab_k++upO0Ym=irmfO9+BbFw@mail.gmail.com>
2015-08-18 4:03 ` Paul Turner
2015-08-18 20:31 ` Tejun Heo
2015-08-18 23:39 ` Kamezawa Hiroyuki
2015-08-19 16:23 ` Tejun Heo
2015-08-19 3:23 ` Mike Galbraith
2015-08-19 16:41 ` Tejun Heo
2015-08-20 4:00 ` Mike Galbraith
2015-08-20 7:52 ` Tejun Heo
2015-08-20 8:47 ` Mike Galbraith
2015-08-21 19:26 ` Paul Turner
2015-08-22 18:29 ` Tejun Heo
2015-08-24 15:47 ` Austin S Hemmelgarn
2015-08-24 17:04 ` Tejun Heo
2015-08-24 19:18 ` Mike Galbraith
2015-08-24 20:00 ` Austin S Hemmelgarn
2015-08-24 20:25 ` Tejun Heo
2015-08-24 21:00 ` Paul Turner
2015-08-24 21:12 ` Tejun Heo
2015-08-24 21:15 ` Paul Turner
2015-08-24 20:54 ` Paul Turner
2015-08-24 21:02 ` Tejun Heo
2015-08-24 21:10 ` Paul Turner
2015-08-24 21:17 ` Tejun Heo
2015-08-24 21:19 ` Paul Turner
2015-08-24 21:40 ` Tejun Heo
2015-08-24 22:03 ` Paul Turner
2015-08-24 22:49 ` Tejun Heo
2015-08-24 23:15 ` Paul Turner
2015-08-25 2:36 ` Kamezawa Hiroyuki
2015-08-25 21:13 ` Tejun Heo
2015-08-25 9:24 ` Ingo Molnar
2015-08-25 10:00 ` Peter Zijlstra
2015-08-25 19:18 ` Tejun Heo
2015-08-24 20:52 ` Paul Turner
2015-08-24 21:36 ` Tejun Heo
2015-08-24 21:58 ` Paul Turner
2015-08-24 22:19 ` Tejun Heo
2015-08-24 23:06 ` Paul Turner
2015-08-25 21:02 ` Tejun Heo
2015-09-02 17:03 ` Tejun Heo
2015-09-09 12:49 ` Paul Turner
2015-09-12 14:40 ` Tejun Heo
2015-09-17 14:35 ` Peter Zijlstra
2015-09-17 14:53 ` Tejun Heo
2015-09-17 15:42 ` Peter Zijlstra
2015-09-17 15:10 ` Peter Zijlstra
2015-09-17 15:52 ` Tejun Heo
2015-09-17 15:53 ` Peter Zijlstra
2015-09-17 23:29 ` Tejun Heo
2015-09-18 11:27 ` Paul Turner
2015-10-01 18:46 ` Tejun Heo
2015-10-15 11:42 ` Paul Turner
2015-10-23 22:21 ` Tejun Heo
2015-10-24 4:36 ` Mike Galbraith
2015-10-25 2:18 ` Tejun Heo [this message]
2015-10-25 3:43 ` Mike Galbraith
2015-10-27 3:16 ` Tejun Heo
2015-10-27 5:42 ` Mike Galbraith
2015-10-27 5:46 ` Tejun Heo
2015-10-27 5:56 ` Mike Galbraith
2015-10-27 6:00 ` Tejun Heo
2015-10-27 6:08 ` Mike Galbraith
2015-10-25 3:54 ` Linus Torvalds
2015-10-25 9:33 ` Ingo Molnar
2015-10-25 10:41 ` Theodore Ts'o
2015-10-25 10:47 ` Florian Weimer
2015-10-25 11:58 ` Theodore Ts'o
2015-10-25 13:17 ` Florian Weimer
2015-10-25 13:40 ` Getrandom wrapper Theodore Ts'o
2015-10-26 13:32 ` Florian Weimer
2015-10-26 14:10 ` [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Peter Zijlstra
2015-08-04 19:32 ` [PATCH v2 " 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=20151025021829.GA15471@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=torvalds@linux-foundation.org \
--cc=umgwanakikbuti@gmail.com \
/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
Powered by JetHome