Thread (38 messages) 38 messages, 8 authors, 2016-10-05

Re: [Documentation] State of CPU controller in cgroup v2

From: Mike Galbraith <hidden>
Date: 2016-08-17 09:33:29
Also in: linux-api, lkml

On Tue, 2016-08-16 at 12:30 -0400, Johannes Weiner wrote:
On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote:
quoted
Also, the argument there seems unfair at best, you don't need cpu-v2 for
buffered write control, you only need memcg and block co-mounted.
Yes, memcg and block agreeing is enough for that case. But I mentioned
a whole bunch of these examples, to make the broader case for a common
controller model.
The core issue I have with that model is that it defines context=mm,
and declares context=task to be invalid, while in reality, both views
are perfectly valid, useful, and in use.  That redefinition of context
is demonstrably harmful when applied to scheduler related controllers,
rendering a substantial portion of to be managed objects completely
unmanageable.  You (collectively) know that full well.

AFAIKT, there is only one viable option, and that is to continue to
allow both.  Whether you like the duality or not (who would), it's
deeply embedded in what's under the controllers, and won't go away.

I'll now go try a little harder while you ponder (or pop) this thought
bubble, see if I can set a new personal best at the art of ignoring. 

(CC did not help btw, your bad if you don't like bubble content)

	-Mike
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help