On 23/11/2018 17.51, Frederic Weisbecker wrote: > On Tue, Sep 18, 2018 at 03:22:13PM +0200, Jan H. Schönherr wrote: >> On 09/17/2018 11:48 AM, Peter Zijlstra wrote: >>> Right, so the whole bandwidth thing becomes a pain; the simplest >>> solution is to detect the throttle at task-pick time, dequeue and try >>> again. But that is indeed quite horrible. >>> >>> I'm not quite sure how this will play out. >>> >>> Anyway, if we pull off this flattening feat, then you can no longer use >>> the hierarchy for this co-scheduling stuff. >> >> Yeah. I might be a bit biased towards keeping or at least not fully throwing >> away >> the nesting of CFS runqueues. ;) > > One detail here, is that hierarchical task group a strong requirement for > cosched > or could you live with it flattened in the end?
Currently, it is a strong requirement. As mentioned at the bottom of https://lkml.org/lkml/2018/10/19/859 it should be possible to pull the hierarchical aspect out of CFS and implement it one level higher. But that would be a major re-design of everything. I use the hierarchical aspect to a) keep coscheduled groups in separate sets of runqeues, so that it is easy to select/balance tasks within a particular group; and b) to implement per-core, per-node, per-system runqueues that represent larger fractions of the system, which then fan out into per-CPU runqueues (eventually). Regards Jan
