From: Suren Baghdasaryan <surenb@google.com> 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>, Tejun Heo <tj@kernel.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>, Todd Kjos <tkjos@google.com>, Joel Fernandes <joelaf@google.com>, Steve Muckle <smuckle@google.com> Subject: Re: [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values Date: Sat, 21 Jul 2018 21:04:23 -0700 [thread overview] Message-ID: <CAJuCfpEwRtXoa_tnWTFP8CuyPMHsLAXky14K_jyphEeo2d32qg@mail.gmail.com> (raw) In-Reply-To: <20180716082906.6061-13-patrick.bellasi@arm.com> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi <patrick.bellasi@arm.com> wrote: > The utilization is a well defined property of tasks and CPUs with an > in-kernel representation based on power-of-two values. > The current representation, in the [0..SCHED_CAPACITY_SCALE] range, > allows efficient computations in hot-paths and a sufficient fixed point > arithmetic precision. > However, the utilization values range is still an implementation detail > which is also possibly subject to changes in the future. > > Since we don't want to commit new user-space APIs to any in-kernel > implementation detail, let's add an abstraction layer on top of the APIs > used by util_clamp, i.e. sched_{set,get}attr syscalls and the cgroup's > cpu.util_{min,max} attributes. > > We do that by adding a couple of conversion function which can be used couple of conversion functions > to conveniently transform utilization/capacity values from/to the internal > SCHED_FIXEDPOINT_SCALE representation to/from a more generic percentage > in the standard [0..100] range. > > Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Tejun Heo <tj@kernel.org> > Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Cc: Paul Turner <pjt@google.com> > Cc: Todd Kjos <tkjos@google.com> > Cc: Joel Fernandes <joelaf@google.com> > Cc: Steve Muckle <smuckle@google.com> > Cc: Juri Lelli <juri.lelli@redhat.com> > Cc: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > --- > Documentation/admin-guide/cgroup-v2.rst | 6 +++--- > include/linux/sched.h | 20 ++++++++++++++++++++ > include/uapi/linux/sched/types.h | 14 ++++++++------ > kernel/sched/core.c | 18 ++++++++++++------ > 4 files changed, 43 insertions(+), 15 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index 328c011cc105..08b8062e55cd 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -973,7 +973,7 @@ All time durations are in microseconds. > A read-write single value file which exists on non-root cgroups. > The default is "0", i.e. no bandwidth boosting. > > - The minimum utilization in the range [0, 1023]. > + The minimum percentage of utilization in the range [0, 100]. > > This interface allows reading and setting minimum utilization clamp > values similar to the sched_setattr(2). This minimum utilization > @@ -981,9 +981,9 @@ All time durations are in microseconds. > > cpu.util_max > A read-write single value file which exists on non-root cgroups. > - The default is "1023". i.e. no bandwidth clamping > + The default is "100". i.e. no bandwidth clamping > > - The maximum utilization in the range [0, 1023]. > + The maximum percentage of utilization in the range [0, 100]. > > This interface allows reading and setting maximum utilization clamp > values similar to the sched_setattr(2). This maximum utilization > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 5dd76a27ec17..f5970903c187 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -321,6 +321,26 @@ struct sched_info { > # define SCHED_FIXEDPOINT_SHIFT 10 > # define SCHED_FIXEDPOINT_SCALE (1L << SCHED_FIXEDPOINT_SHIFT) > > +static inline unsigned int scale_from_percent(unsigned int pct) > +{ > + WARN_ON(pct > 100); > + > + return ((SCHED_FIXEDPOINT_SCALE * pct) / 100); > +} > + > +static inline unsigned int scale_to_percent(unsigned int value) > +{ > + unsigned int rounding = 0; > + > + WARN_ON(value > SCHED_FIXEDPOINT_SCALE); > + > + /* Compensate rounding errors for: 0, 256, 512, 768, 1024 */ > + if (likely((value & 0xFF) && ~(value & 0x700))) > + rounding = 1; Hmm. I don't think ~(value & 0x700) will ever yield FALSE... What am I missing? > + > + return (rounding + ((100 * value) / SCHED_FIXEDPOINT_SCALE)); > +} > + > struct load_weight { > unsigned long weight; > u32 inv_weight; > diff --git a/include/uapi/linux/sched/types.h b/include/uapi/linux/sched/types.h > index 7421cd25354d..e2c2acb1c6af 100644 > --- a/include/uapi/linux/sched/types.h > +++ b/include/uapi/linux/sched/types.h > @@ -84,15 +84,17 @@ struct sched_param { > * > * @sched_util_min represents the minimum utilization > * @sched_util_max represents the maximum utilization > + * @sched_util_min represents the minimum utilization percentage > + * @sched_util_max represents the maximum utilization percentage > * > - * Utilization is a value in the range [0..SCHED_CAPACITY_SCALE] which > - * represents the percentage of CPU time used by a task when running at the > - * maximum frequency on the highest capacity CPU of the system. Thus, for > - * example, a 20% utilization task is a task running for 2ms every 10ms. > + * Utilization is a value in the range [0..100] which represents the > + * percentage of CPU time used by a task when running at the maximum frequency > + * on the highest capacity CPU of the system. Thus, for example, a 20% > + * utilization task is a task running for 2ms every 10ms. > * > - * A task with a min utilization value bigger then 0 is more likely to be > + * A task with a min utilization value bigger then 0% is more likely to be > * scheduled on a CPU which can provide that bandwidth. > - * A task with a max utilization value smaller then 1024 is more likely to be > + * A task with a max utilization value smaller then 100% is more likely to be > * scheduled on a CPU which do not provide more then the required bandwidth. > */ > struct sched_attr { > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 42cff5ffddae..da7b8630cc8d 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -1381,7 +1381,7 @@ static inline int __setscheduler_uclamp(struct task_struct *p, > > if (attr->sched_util_min > attr->sched_util_max) > return -EINVAL; > - if (attr->sched_util_max > SCHED_CAPACITY_SCALE) > + if (attr->sched_util_max > 100) > return -EINVAL; > > mutex_lock(&uclamp_mutex); > @@ -1389,12 +1389,12 @@ static inline int __setscheduler_uclamp(struct task_struct *p, > /* Update min utilization clamp */ > uc_se = &p->uclamp[UCLAMP_MIN]; > retval |= uclamp_group_get(p, NULL, UCLAMP_MIN, uc_se, > - attr->sched_util_min); > + scale_from_percent(attr->sched_util_min)); > > /* Update max utilization clamp */ > uc_se = &p->uclamp[UCLAMP_MAX]; > retval |= uclamp_group_get(p, NULL, UCLAMP_MAX, uc_se, > - attr->sched_util_max); > + scale_from_percent(attr->sched_util_max)); > > mutex_unlock(&uclamp_mutex); > > @@ -5493,6 +5493,8 @@ SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr, > if (task_group(p)->uclamp[UCLAMP_MAX].value < attr.sched_util_max) > attr.sched_util_max = task_group(p)->uclamp[UCLAMP_MAX].value; > #endif > + attr.sched_util_min = scale_to_percent(attr.sched_util_min); > + attr.sched_util_max = scale_to_percent(attr.sched_util_max); > #endif > > rcu_read_unlock(); > @@ -7284,8 +7286,10 @@ static int cpu_util_min_write_u64(struct cgroup_subsys_state *css, > struct task_group *tg; > int ret = -EINVAL; > > - if (min_value > SCHED_CAPACITY_SCALE) > + /* Check range and scale to internal representation */ > + if (min_value > 100) > return -ERANGE; > + min_value = scale_from_percent(min_value); > > mutex_lock(&uclamp_mutex); > rcu_read_lock(); > @@ -7316,8 +7320,10 @@ static int cpu_util_max_write_u64(struct cgroup_subsys_state *css, > struct task_group *tg; > int ret = -EINVAL; > > - if (max_value > SCHED_CAPACITY_SCALE) > + /* Check range and scale to internal representation */ > + if (max_value > 100) > return -ERANGE; > + max_value = scale_from_percent(max_value); > > mutex_lock(&uclamp_mutex); > rcu_read_lock(); > @@ -7352,7 +7358,7 @@ static inline u64 cpu_uclamp_read(struct cgroup_subsys_state *css, > util_clamp = tg->uclamp[clamp_id].value; > rcu_read_unlock(); > > - return util_clamp; > + return scale_to_percent(util_clamp); > } > > static u64 cpu_util_min_read_u64(struct cgroup_subsys_state *css, > -- > 2.17.1 >
next prev parent reply other threads:[~2018-07-22 4:05 UTC|newest] Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-16 8:28 [PATCH v2 00/12] Add utilization clamping support Patrick Bellasi 2018-07-16 8:28 ` [PATCH v2 01/12] sched/core: uclamp: extend sched_setattr to support utilization clamping Patrick Bellasi 2018-07-17 17:50 ` Joel Fernandes 2018-07-18 8:42 ` Patrick Bellasi 2018-07-18 17:02 ` Joel Fernandes 2018-07-17 18:04 ` Joel Fernandes 2018-07-16 8:28 ` [PATCH v2 02/12] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups Patrick Bellasi 2018-07-19 23:51 ` Suren Baghdasaryan 2018-07-20 15:11 ` Patrick Bellasi 2018-07-21 0:25 ` Suren Baghdasaryan 2018-07-23 13:36 ` Patrick Bellasi 2018-07-16 8:28 ` [PATCH v2 03/12] sched/core: uclamp: add CPU's clamp groups accounting Patrick Bellasi 2018-07-20 20:25 ` Suren Baghdasaryan 2018-07-16 8:28 ` [PATCH v2 04/12] sched/core: uclamp: update CPU's refcount on clamp changes Patrick Bellasi 2018-07-16 8:28 ` [PATCH v2 05/12] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Patrick Bellasi 2018-07-16 8:29 ` [PATCH v2 06/12] sched/cpufreq: uclamp: add utilization clamping for RT tasks Patrick Bellasi 2018-07-16 8:29 ` [PATCH v2 07/12] sched/core: uclamp: enforce last task UCLAMP_MAX Patrick Bellasi 2018-07-21 1:23 ` Suren Baghdasaryan 2018-07-23 15:02 ` Patrick Bellasi 2018-07-23 16:40 ` Suren Baghdasaryan 2018-07-16 8:29 ` [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller Patrick Bellasi 2018-07-21 2:37 ` Suren Baghdasaryan 2018-07-21 3:16 ` Suren Baghdasaryan 2018-07-23 15:17 ` Patrick Bellasi 2018-07-23 15:30 ` Tejun Heo 2018-07-23 17:22 ` Patrick Bellasi 2018-07-24 13:29 ` Tejun Heo 2018-07-24 15:39 ` Patrick Bellasi 2018-07-27 0:39 ` Joel Fernandes 2018-07-27 8:09 ` Quentin Perret 2018-07-16 8:29 ` [PATCH v2 09/12] sched/core: uclamp: map TG's clamp values into CPU's clamp groups Patrick Bellasi 2018-07-16 8:29 ` [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps Patrick Bellasi 2018-07-22 3:05 ` Suren Baghdasaryan 2018-07-23 15:40 ` Patrick Bellasi 2018-07-23 17:11 ` Suren Baghdasaryan 2018-07-24 9:56 ` Patrick Bellasi 2018-07-24 15:28 ` Suren Baghdasaryan 2018-07-24 15:49 ` Patrick Bellasi 2018-07-16 8:29 ` [PATCH v2 11/12] sched/core: uclamp: update CPU's refcount on TG's clamp changes Patrick Bellasi 2018-07-22 3:17 ` Suren Baghdasaryan 2018-07-16 8:29 ` [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values Patrick Bellasi 2018-07-22 4:04 ` Suren Baghdasaryan [this message] 2018-07-24 16:43 ` Patrick Bellasi 2018-07-24 17:11 ` Suren Baghdasaryan 2018-07-24 17:17 ` Patrick Bellasi 2018-07-17 13:03 ` [PATCH v2 00/12] Add utilization clamping support Joel Fernandes 2018-07-17 13:41 ` 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=CAJuCfpEwRtXoa_tnWTFP8CuyPMHsLAXky14K_jyphEeo2d32qg@mail.gmail.com \ --to=surenb@google.com \ --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=tj@kernel.org \ --cc=tkjos@google.com \ --cc=vincent.guittot@linaro.org \ --cc=viresh.kumar@linaro.org \ --subject='Re: [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).