linux-kernel - Re: [RFCv4 1/6] sched/core: add utilization clamping to CPU controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Aug 2017 11:23:03 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Patrick Bellasi <patrick.bellasi@....com>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Paul Turner <pjt@...gle.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Juri Lelli <juri.lelli@....com>,
        Tim Murray <timmurray@...gle.com>,
        Todd Kjos <tkjos@...roid.com>,
        Andres Oportus <andresoportus@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [RFCv4 1/6] sched/core: add utilization clamping to CPU
 controller

Hello,

No idea whether this makes sense overall.  I'll just comment on the
cgroup interface part.

On Thu, Aug 24, 2017 at 07:08:52PM +0100, Patrick Bellasi wrote:
> This patch extends the CPU controller by adding a couple of new attributes,
> util_min and util_max, which can be used to enforce frequency boosting and
> capping. Specifically:
> 
> - util_min: defines the minimum CPU utilization which should be considered,
> 	    e.g. when  schedutil selects the frequency for a CPU while a
> 	    task in this group is RUNNABLE.
> 	    i.e. the task will run at least at a minimum frequency which
> 	         corresponds to the min_util utilization
> 
> - util_max: defines the maximum CPU utilization which should be considered,
> 	    e.g. when schedutil selects the frequency for a CPU while a
> 	    task in this group is RUNNABLE.
> 	    i.e. the task will run up to a maximum frequency which
> 	         corresponds to the max_util utilization

I'm not sure min/max are the right names here.  min/low/high/max are
used to designate guarantees and limits on resources and the above is
more restricting the range of an attribute.  I'll think more about
what'd be better names here.

> These attributes:
> a) are tunable at all hierarchy levels, i.e. at root group level too, thus
>    allowing to defined minimum and maximum frequency constraints for all
>    otherwise non-classified tasks (e.g. autogroups)

The problem with doing the above is two-fold.

1. The feature becomes inaccessible without cgroup even though it
   doesn't have much to do with cgroup at system level.

2. For the above and other historical reasons, most other features
   have a separate way to configure at the system level.

I think it'd be better to keep the root level control outside cgorup.

> b) allow to create subgroups of tasks which are not violating the
>    utilization constraints defined by the parent group.

The problem with doing the above is that it ties the configs of a
cgroup with its ancestors and that gets weird across delegation
boundaries.  Other resource knobs don't behave this way - a descendant
cgroup can have any memory.low/high/max values and an ancestor
changing config doesn't destory its descendants' configs.  Please
follow the same convention.

> Tasks on a subgroup can only be more boosted and/or capped, which is
> matching with the "limits" schema proposed by the "Resource Distribution
> Model (RDM)" suggested by the CGroups v2 documentation:
>    Documentation/cgroup-v2.txt

So, the guarantee side (min / low) shouldn't allow the descendants to
have more.  ie. if memory.low is 512M at the parent, its children can
never have more than 512M of low protection.  Given that "boosting"
means more CPU consumption, I think it'd make more sense to follow
such semantics - ie. a descendant cannot have higher boosting than the
lowest of its ancestors.

Thanks.

-- 
tejun