Message-ID: <20161027183017.GA15876@htj.duckdns.org>
Date:   Thu, 27 Oct 2016 14:30:17 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Patrick Bellasi <patrick.bellasi@....com>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Steve Muckle <steve.muckle@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Todd Kjos <tkjos@...gle.com>,
        Srinath Sridharan <srinathsr@...gle.com>,
        Andres Oportus <andresoportus@...gle.com>,
        Juri Lelli <juri.lelli@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Chris Redpath <chris.redpath@....com>,
        Robin Randhawa <robin.randhawa@....com>,
        Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC v2 5/8] sched/tune: add initial support for CGroups based
 boosting

Hello, Patrick.

On Thu, Oct 27, 2016 at 06:41:05PM +0100, Patrick Bellasi wrote:
> To support task performance boosting, the usage of a single knob has the
> advantage to be a simple solution, both from the implementation and the
> usability standpoint.  However, on a real system it can be difficult to
> identify a single value for the knob which fits the needs of multiple
> different tasks. For example, some kernel threads and/or user-space
> background services should be better managed the "standard" way while we
> still want to be able to boost the performance of specific workloads.
> 
> In order to improve the flexibility of the task boosting mechanism this
> patch is the first of a small series which extends the previous
> implementation to introduce a "per task group" support.
> 
> This first patch introduces just the basic CGroups support, a new
> "schedtune" CGroups controller is added which allows to configure
> different boost value for different groups of tasks.
> To keep the implementation simple while still supporting an effective
> boosting strategy, the new controller:
>   1. allows only a two layer hierarchy
>   2. supports only a limited number of boost groups
> 
> A two layer hierarchy allows to place each task either:
>   a) in the root control group
>      thus being subject to a system-wide boosting value
>   b) in a child of the root group
>      thus being subject to the specific boost value defined by that
>      "boost group"
> 
> The limited number of "boost groups" supported is mainly motivated by
> the observation that in a real system it could be useful to have only
> few classes of tasks which deserve different treatment.
> For example, background vs foreground or interactive vs low-priority.
> 
> As an additional benefit, a limited number of boost groups allows also
> to have a simpler implementation, especially for the code required to
> compute the boost value for CPUs which have RUNNABLE tasks belonging to
> different boost groups.

So, skipping on the actual details of boosting mechanism, in terms of
cgroup support, it should be integrated into the existing cpu
controller and have proper support for hierarchy.  Note that hierarchy
support doesn't necessarily mean that boosting itself has to be
hierarchical.  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.

Thanks.

-- 
tejun

Powered by blists - more mailing lists