Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4467844imm; Sat, 21 Jul 2018 21:06:17 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe56NvB9q7mWC94JimKNn9FfRIN5fJxvNf+xNUdKfq/mUHSh9MIs3QBr11UYjnm2v/b39Xt X-Received: by 2002:a63:a347:: with SMTP id v7-v6mr7314850pgn.182.1532232377270; Sat, 21 Jul 2018 21:06:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532232377; cv=none; d=google.com; s=arc-20160816; b=IKguRBftrsJTvcU8I5/xR0iQ+3dA10G/G3hC+u3I/wuVAikYO9a/kiQEvYJyV1LUEp p9KhvRmBAyrYe9wM7fb7kSJ4mZq3Kyss47xAF5mGNChLqBm3Yu22q+nqZTI3Up2IlJ8H oQAi96KcSgLkIB5oFUeusp0JPNwdH455oEKvVyVuzfC2/3nxSujuOxs2U7GTVvcQG9mB unJPD0Sb8U42CXQmMA+B8l0w20yKeWKvimiAbrKkLEPau2JJnQT22mBD2HT1XXCgLXEY oWVO6oj83FAmICu92ALa74Xw7bTFUOeyqz9aRrrmyYHUt0O9zMlmGPxst5biSiA42wko D9pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=LXDzc1qoYT7J1vwrsYL8VuExy7+VYQyl4k10vq5jhVI=; b=dCuTSz+JGn5u0aw6LMmgcfy42rlhlExYVZZysCuXtdfnn+E47GMsgBhQUHeg8FMkdq NuTL6OtUyOGgIsh4p8qylnXYsjfo+tMXUlPDiQKhit/Z/1BqIGMfhuOy6i1bzbKsrb8M cFKERDIO9aJjv5gifHLoCRCb7CF9foiHto3nrNcewfNDeaWhgkrwvbnocFjt6VJRS2xv PkhZ+30kAiPMFJw9Sef32c55PUj4a88Fb4Unh6A5YrbPHkHJ4Uu0/qctLpSizwrHF59v ERSedqF0Rn4IWAeziMbSZ9pn7L64SExGh50/DbdSvM4mv6G8Qdv3DASenUHb1gljlHbr 923Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZZymsMsm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p14-v6si5713480pfk.275.2018.07.21.21.05.50; Sat, 21 Jul 2018 21:06:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ZZymsMsm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727778AbeGVE7f (ORCPT + 99 others); Sun, 22 Jul 2018 00:59:35 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:33384 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727520AbeGVE7f (ORCPT ); Sun, 22 Jul 2018 00:59:35 -0400 Received: by mail-io0-f193.google.com with SMTP id z20-v6so12987858iol.0 for ; Sat, 21 Jul 2018 21:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LXDzc1qoYT7J1vwrsYL8VuExy7+VYQyl4k10vq5jhVI=; b=ZZymsMsmtjAFfkXkPCEO7iv4t+muDG/PNuVEQ1ypZK1SQvx6dWtZ/28NKZArBJFkZP RQXcFsaRLbjhRTmE4B/EnSauNLARURTy9T6UbRlw/JtKy5Dqk+XKt6isjk6LvgqyxG9p ZHxYptTe44wo7vobuHhHrSGJJNbyar2ENefwMgXzDiUDSpbRjHvwbbUeydoDJjKK3Z9K T0XdJSypQ8VcSzv4uxVUu26mXseAl/eCgET8GdtjW/c2LZfKTzlQL5tbag5MzToJcyPS 7qcpbCcBoRkWyEGZ+ScOWKVmWouRwqhbwcn7iuvhdmvrSQ9xghPCqmJPZxjOi8YeQj2P koUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LXDzc1qoYT7J1vwrsYL8VuExy7+VYQyl4k10vq5jhVI=; b=rpEJ1LLDNxBq0eqCBbcSMLU8sAoIW5KqPTc7sI0WtvuVJxELfYVXT+7IQeRNpvm0id P4o4PgBOPK7IdugSO/POdA5Zo/WnA4JtNb9zC6M4ZVbWfUPj6/8TJEnedNTFyTK9n/mM OVONS9xkoXwhNhD7QV7jfsmYgcBiMkxxUHf4420sVkr1ELMvqXqF6+SZJkIjUSLc/jNN fLTJUnaAGV4MfO1qDrH4rQhB6SWyJnKiLx10hvIYK2QkD6j08y3vaGCJld6LYnN66w69 FuMBAYyvmgFU2ZKmawSBMvdqOzFLkXSEoSFkAqKJJq6MIySlZzTJTKwG/DaCDiqCGctJ KFOQ== X-Gm-Message-State: AOUpUlFlPu2RmVkgjXMBhD9Sq3XsGCmai3BZaQgwh+9XsaAkDiSDYmya 7fY/XvAMpV9+8LU+PZDQU9P+1vHA31H+EXgQgkSpyEyNu7c= X-Received: by 2002:a5e:8341:: with SMTP id y1-v6mr5774902iom.183.1532232264068; Sat, 21 Jul 2018 21:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:e445:0:0:0:0:0 with HTTP; Sat, 21 Jul 2018 21:04:23 -0700 (PDT) In-Reply-To: <20180716082906.6061-13-patrick.bellasi@arm.com> References: <20180716082906.6061-1-patrick.bellasi@arm.com> <20180716082906.6061-13-patrick.bellasi@arm.com> From: Suren Baghdasaryan Date: Sat, 21 Jul 2018 21:04:23 -0700 Message-ID: Subject: Re: [PATCH v2 12/12] sched/core: uclamp: use percentage clamp values To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi 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 > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Tejun Heo > Cc: Rafael J. Wysocki > Cc: Paul Turner > Cc: Todd Kjos > Cc: Joel Fernandes > Cc: Steve Muckle > Cc: Juri Lelli > 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 >