From: Tejun Heo <tj@kernel.org> To: Patrick Bellasi <patrick.bellasi@arm.com> Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Viresh Kumar <viresh.kumar@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, Paul Turner <pjt@google.com>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Morten Rasmussen <morten.rasmussen@arm.com>, Juri Lelli <juri.lelli@redhat.com>, Joel Fernandes <joelaf@google.com>, Steve Muckle <smuckle@google.com> Subject: Re: [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller Date: Mon, 9 Apr 2018 15:24:17 -0700 Message-ID: <20180409222417.GK3126663@devbig577.frc2.facebook.com> (raw) In-Reply-To: <20180409165615.2326-5-patrick.bellasi@arm.com> Hello, Patrick. Comments purely on cgroup interface side. On Mon, Apr 09, 2018 at 05:56:12PM +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 too enthusiastic about util_min/max given that it can easily be read as actual utilization based bandwidth control when what's actually implemented, IIUC, is affecting CPU frequency selection. Maybe something like cpu.freq.min/max are better names? > These attributes: > a) are tunable at all hierarchy levels, i.e. at root group level too, thus > allowing to define the minimum and maximum frequency constraints for all > otherwise non-classified tasks (e.g. autogroups) and to be a sort-of > replacement for cpufreq's powersave, ondemand and performance > governors. This is a problem which exists for all other interfaces. For historical and other reasons, at least till now, we've opted to put everything at system level outside of cgroup interface. We might change this in the future and duplicate system-level information and interfaces in the root cgroup but we wanna do that in a more systemtic fashion than adding an one-off knob in the cgroup root. Besides, if a feature makes sense at the system level which is the cgroup root, it makes sense without cgroup mounted or enabled, so it needs a place outside cgroup one way or the other. > b) allow to create subgroups of tasks which are not violating the > utilization constraints defined by the parent group. Tying creation / config operations to the config propagation doesn't work well with delegation and is inconsistent with what other controllers are doing. For cases where the propagated config being visible in a sub cgroup is necessary, please add .effective files. > Tasks on a subgroup can only be more boosted and/or capped, which is Less boosted. .low at a parent level must set the upper bound of .low that all its descendants can have. Thanks. -- tejun
next prev parent reply index Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-09 16:56 [PATCH 0/7] Add utilization clamping support Patrick Bellasi 2018-04-09 16:56 ` [PATCH 1/7] sched/core: uclamp: add CPU clamp groups accounting Patrick Bellasi 2018-04-13 8:26 ` Peter Zijlstra 2018-04-13 10:22 ` Peter Zijlstra 2018-04-13 11:04 ` Patrick Bellasi 2018-04-13 11:15 ` Peter Zijlstra 2018-04-13 8:40 ` Peter Zijlstra 2018-04-13 11:17 ` Patrick Bellasi 2018-04-13 11:29 ` Peter Zijlstra 2018-04-13 11:33 ` Patrick Bellasi 2018-04-13 8:43 ` Peter Zijlstra 2018-04-13 11:15 ` Patrick Bellasi 2018-04-13 11:36 ` Peter Zijlstra 2018-04-13 11:47 ` Patrick Bellasi 2018-04-13 11:52 ` Patrick Bellasi 2018-04-13 12:44 ` Peter Zijlstra 2018-04-13 9:30 ` Peter Zijlstra 2018-04-13 9:38 ` Peter Zijlstra 2018-04-13 9:46 ` Peter Zijlstra 2018-04-13 11:08 ` Patrick Bellasi 2018-04-13 11:19 ` Peter Zijlstra 2018-04-09 16:56 ` [PATCH 2/7] sched/core: uclamp: map TASK clamp values into CPU clamp groups Patrick Bellasi 2018-04-09 16:56 ` [PATCH 3/7] sched/core: uclamp: extend sched_setattr to support utilization clamping Patrick Bellasi 2018-04-09 16:56 ` [PATCH 4/7] sched/core: uclamp: add utilization clamping to the CPU controller Patrick Bellasi 2018-04-09 22:24 ` Tejun Heo [this message] 2018-04-10 17:16 ` Patrick Bellasi 2018-04-10 20:05 ` Tejun Heo 2018-04-21 21:08 ` Joel Fernandes 2018-04-26 18:58 ` Tejun Heo 2018-04-09 16:56 ` [PATCH 5/7] sched/core: uclamp: use TG clamps to restrict TASK clamps Patrick Bellasi 2018-04-09 16:56 ` [PATCH 6/7] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Patrick Bellasi 2018-04-09 16:56 ` [PATCH 7/7] sched/cpufreq: uclamp: add utilization clamping for RT tasks Patrick Bellasi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180409222417.GK3126663@devbig577.frc2.facebook.com \ --to=tj@kernel.org \ --cc=dietmar.eggemann@arm.com \ --cc=joelaf@google.com \ --cc=juri.lelli@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=morten.rasmussen@arm.com \ --cc=patrick.bellasi@arm.com \ --cc=peterz@infradead.org \ --cc=pjt@google.com \ --cc=rafael.j.wysocki@intel.com \ --cc=smuckle@google.com \ --cc=vincent.guittot@linaro.org \ --cc=viresh.kumar@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git