Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1372625 > unrolled thread
| Started by | Tejun Heo <tj@kernel.org> |
|---|---|
| First post | 2016-04-06 18:00 +0200 |
| Last post | 2016-04-08 05:20 +0200 |
| Articles | 5 on this page of 25 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-06 18:00 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 08:50 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Johannes Weiner <hannes@cmpxchg.org> - 2016-04-07 09:40 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 10:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Johannes Weiner <hannes@cmpxchg.org> - 2016-04-07 11:30 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 12:50 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-07 21:50 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 22:30 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-08 22:20 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-09 08:20 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-09 15:40 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-13 00:30 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-13 09:50 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-13 18:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-13 21:20 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-14 08:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Tejun Heo <tj@kernel.org> - 2016-04-14 22:00 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-15 04:50 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-09 18:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-07 10:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 10:30 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Johannes Weiner <hannes@cmpxchg.org> - 2016-04-07 21:10 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Peter Zijlstra <peterz@infradead.org> - 2016-04-07 21:40 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Johannes Weiner <hannes@cmpxchg.org> - 2016-04-07 22:30 +0200
Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP Mike Galbraith <umgwanakikbuti@gmail.com> - 2016-04-08 05:20 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-04-07 10:30 +0200 |
| Message-ID | <rldua-10J-5@gated-at.bofh.it> |
| In reply to | #1373122 |
On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> There was a lot of back and forth whether we should add a second set
> of knobs just to control the local tasks separately from the subtree,
> but ended up concluding that the situation can be expressed more
> clearly by creating dedicated leaf subgroups for stuff like management
> software and launchers instead, so that their memory pools/LRUs are
> clearly delineated from other groups and seperately controllable. And
> we couldn't think of any meaningful configuration that could not be
> expressed in that scheme. I mean, it's the same thing, right?
No, not the same.
R
/ | \
t1 t2 A
/ \
t3 t4
Is fundamentally different from:
R
/ \
L A
/ \ / \
t1 t2 t3 t4
Because if in the first hierarchy you add a task (t5) to R, all of its A
will run at 1/4th of total bandwidth where before it had 1/3rd, whereas
with the second example, if you add our t5 to L, A doesn't get any less
bandwidth.
Please pull your collective heads out of the systemd arse and start
thinking.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-04-07 21:10 +0200 |
| Message-ID | <rlntw-7U-7@gated-at.bofh.it> |
| In reply to | #1373139 |
On Thu, Apr 07, 2016 at 10:28:10AM +0200, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote: > > There was a lot of back and forth whether we should add a second set > > of knobs just to control the local tasks separately from the subtree, > > but ended up concluding that the situation can be expressed more > > clearly by creating dedicated leaf subgroups for stuff like management > > software and launchers instead, so that their memory pools/LRUs are > > clearly delineated from other groups and seperately controllable. And > > we couldn't think of any meaningful configuration that could not be > > expressed in that scheme. I mean, it's the same thing, right? > > No, not the same. > > > R > / | \ > t1 t2 A > / \ > t3 t4 > > > Is fundamentally different from: > > > R > / \ > L A > / \ / \ > t1 t2 t3 t4 > > > Because if in the first hierarchy you add a task (t5) to R, all of its A > will run at 1/4th of total bandwidth where before it had 1/3rd, whereas > with the second example, if you add our t5 to L, A doesn't get any less > bandwidth. I didn't mean the same exact configuration, I meant being able to configure with the same outcome of resource distribution. All this means here is that if you want to change the shares allocated to the tasks in R (or then L) you have to be explicit about it and update the weight configuration in L. Again, it's not gratuitous, it's based on the problems this concept in the interface created in more comprehensive container deployments. > Please pull your collective heads out of the systemd arse and start > thinking. I don't care about systemd here. In fact, in 5 years of rewriting the memory controller, zero percent of it was driven by systemd and most of it from Google's feedback at LSF and email since they had by far the most experience and were pushing the frontier. And even though the performance and overhead of the memory controller was absolutely abysmal - routinely hitting double digits in page fault profiles - the discussions *always* centered around the interface and configuration. IMO, this thread is a little too focused on the reality of a single resource controller, when in real setups it doesn't exist in a vacuum. What these environments need is to robustly divide the machine up into parcels to isolate thousands of jobs on X dimensions at the same time: allocate CPU time, allocate memory, allocate IO. And then on top of that implement higher concepts such as dirty page quotas and writeback, accounting for kswapd's cpu time based on who owns the memory it reclaims, accounting IO time for the stuff it swaps out etc. That *needs* all three resources to be coordinated. You disparagingly called it the lowest common denominator, but the thing is that streamlining the controllers and coordinating them around shared resource domains gives us much more powerful and robust ways to allocate the *machines* as a whole, and allows the proper tracking and accounting of cross-domain operations such as writeback that wasn't even possible before. And all that in a way that doesn't have the same usability pitfalls that v1 had when you actually push this stuff beyond the "i want to limit the cpu cycles of this one service" and move towards "this machine is an anonymous node in a data center and I want it to host thousands of different workloads - some sensitive to latency, some that only care about throughput - and they better not step on each other's toes on *any* of the resource pools." Those are my primary concerns when it comes to the v2 interface, and I think focusing too much on what's theoretically possible with a single controller is missing the bigger challenge of allocating machines.
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2016-04-07 21:40 +0200 |
| Message-ID | <rlnWy-kj-11@gated-at.bofh.it> |
| In reply to | #1373680 |
On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote: > All this means here is that if you want to change the shares allocated > to the tasks in R (or then L) you have to be explicit about it and > update the weight configuration in L. Updating the weight of L for every task spawned and killed is simply not an option. The fact that you're not willing to admit to this is troubling, but does confirm I can stop spending time on anything cgroup v2. cpu-cgroup just isn't going to move to this inferior interface.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Date | 2016-04-07 22:30 +0200 |
| Message-ID | <rloIV-Ti-9@gated-at.bofh.it> |
| In reply to | #1373702 |
On Thu, Apr 07, 2016 at 09:31:27PM +0200, Peter Zijlstra wrote: > On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote: > > > All this means here is that if you want to change the shares allocated > > to the tasks in R (or then L) you have to be explicit about it and > > update the weight configuration in L. > > Updating the weight of L for every task spawned and killed is simply not > an option. > > The fact that you're not willing to admit to this is troubling, but does > confirm I can stop spending time on anything cgroup v2. cpu-cgroup just > isn't going to move to this inferior interface. I guess I walked right into that one, didn't I ;-) It probably makes more sense to discuss a real-life workload instead of a diagram. Obviously, if the threadpool size is highly variable it's not reasonable to ask the user to track every update and accordingly reconfigure the controller. I fully agree with you there. All I meant to point out is that the *implicit* behavior of the v1 interface did create real problems, to show you that this is not a one-sided discussion and that there are real life concerns that played into the decision of not letting loose tasks compete with groups. If this is a real workload rather than a thought experiment, it will need to be supported in v2 as well - just if we can help it hopefully without reverting to the tricky behavior of the v1 controller. One possible solution I could imagine for example is adding the option to configure a groups weight such that its dynamically based on the # of threads. But it depends on what the exact requirements are here. Could you explain what this workload is so it's easier to reason about? Mike, is that the one you referred to with one group per customer account? If so, would you have a pointer to where you outline it?
[toc] | [prev] | [next] | [standalone]
| From | Mike Galbraith <umgwanakikbuti@gmail.com> |
|---|---|
| Date | 2016-04-08 05:20 +0200 |
| Message-ID | <rlv7I-5Vv-3@gated-at.bofh.it> |
| In reply to | #1373724 |
On Thu, 2016-04-07 at 16:23 -0400, Johannes Weiner wrote: > Mike, is that the one you referred to with one group per customer > account? If so, would you have a pointer to where you outline it? The usage I loosely outlined, I did in this thread. All of the gory details I do not have, do not want, and could not provide if I did. -Mike
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web