Re: [RFC v2 5/8] sched/tune: add initial support for CGroups based boosting

[Tejun Heo <tj@kernel.org>]

Hello, Patrick.

On Thu, Oct 27, 2016 at 09:14:39PM +0100, Patrick Bellasi wrote:
> I'm wondering also how much confusing and complex it can be to
> configure a system where you have not overlapping groups of tasks with
> different bandwidth and boosting requirements.
> 
> For example, let assume we have three tasks: A, B, and C and we want:
> 
>    Bandwidth:  10% for A and B,  20% for C
>    Boost:      10% for A,         0% for B and C
> 
> IMO, configuring such a set of constraints would be quite complex if
> we expose the boost value through the cpu controller.

Going back to your use case point, when would we realistically need
this?

> > Note that hierarchy
> > support doesn't necessarily mean that boosting itself has to be
> > hierarchical.
> 
> Initially I've actually considered such a design, however...
> 
> >It can be, for example, something along the line of
> > "the descendants are allowed upto this level of boosting" so that the
> > hierarchy just serves to assign the appropriate boosting values to the
> > groups of tasks.
> 
> ... the current "single layer hierarchy" has been proposed instead for
> two main reasons.
> 
> First, we was not able to think about realistic use-cases where we
> need this "up to this level" semantic.
> For boosting purposes, tasks are grouped based on their role and/or
> importance in the system. This property is usually defined in
> "absolute" terms instead of "relative" therms.
> Does it make sense to say that task A can be boosted only up to how
> much is task B? In our experience probably never.

There are basic semantics that people expect when they use cgroup for
resource control and it enables things like layering and delegating
configuration.

> The second reason is mainly related to the possibility to have an
> efficient and low-overhead implementation. The currently defined
> semantic for CPU boosting requires to perform certain operations at
> each task enqueue and dequeue events. Some of these operations are
> part of the hot path in the scheduler code. The flat hierarchy allows
> to use per-cpu data structures and algorithms which aims at being
> efficient in reducing the overheads incurred in doing the required
> accounting.

Unless I'm misunderstanding, the actually applied attributes should be
calculable during config changes or task migration, right?  The
hierarchy's function would be allowing layering and delegating
configurations and shouldn't get in the way of actual enforcement.

> As a final remark, I would like to say that Google is currently using
> SchedTune in Android to classify tasks by "importance" and feed this
> information into the scheduler. Doing this exercise, so far we did not
> spot limitations related to the usage of a flat hierarchy.
> 
> However, I like to have this discussion, which it's actually the main
> goal of this RFC. My suggestion is just that we should think about
> use-cases before and than introduce a more complex solution, but only
> if we convince ourself that it can bring more benefits than burdens in
> code maintainability.
> 
> Is your request for a "proper support for hierarchy" somehow related to
> the requirements for the "unified hierarchy"? Or do you see also other
> more functional/semantic aspects?

Not necessarily.  In general, all controllers, whether on v1 or v2,
should be fully hierarchical for reasons mentioned above.  I get that
flat was fine for android but flat hierarchy would be fine for most
controllers for android.  That's not the only use case we should be
considering, right?

> > Thanks.
> 
> If you are going to attend LPC next week, I hope we can have a chat on
> these topics.

Yeah, sure, I'll be around till Thursday.  Let's chat there.

Thanks.

-- 
tejun