linux-kernel - Re: [PATCH] sched/debug: Fix requested task uclamp values shown in procfs

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]

Message-ID: <jhjblmvu5nn.mognet@arm.com>
Date:   Sun, 10 May 2020 17:16:28 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     Pavankumar Kondeti <pkondeti@...eaurora.org>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Qais Yousef <qais.yousef@....com>
Subject: Re: [PATCH] sched/debug: Fix requested task uclamp values shown in procfs


On 10/05/20 13:56, Pavankumar Kondeti wrote:
> The intention of commit 96e74ebf8d59 ("sched/debug: Add task uclamp
> values to SCHED_DEBUG procfs") was to print requested and effective
> task uclamp values. The requested values printed are read from p->uclamp,
> which holds the last effective values. Fix this by printing the values
> from p->uclamp_req.
>
> Fixes: 96e74ebf8d59 ("sched/debug: Add task uclamp values to SCHED_DEBUG procfs")
> Signed-off-by: Pavankumar Kondeti <pkondeti@...eaurora.org>

Argh, Qais pointed this out to me ~ a week ago, and I left this in my todo
stack. I goofed up, sorry!

As Pavan points out, p->uclamp[foo] is just a cache of uclamp_eff_value(p,
foo) from the last time p was enqueued and runnable - what we are
interested in is indeed comparing this with the *requested* value.

I wanted to send an example along with a patch, I guess that's the kick I
needed!


My setup is a busy loop, its per-task clamps are set to (256, 768) via
sched_setattr(), and it's shoved in a cpu cgroup with uclamp settings of
(50%, 50%)

On the current master (e99332e7b4cd ("gcc-10: mark more functions __init to
avoid section mismatch warnings")), this gives me:

  $ uclamp-get $PID # via sched_getattr()
  uclamp.min=256 uclamp.max=768

  $ cat /proc/$PID/sched | grep uclamp
  uclamp.min                                   :                  256
  uclamp.max                                   :                  512
  effective uclamp.min                         :                  256
  effective uclamp.max                         :                  512

With Pavan's patch, I get:

  $ uclamp-get $PID # via sched_getattr()
  uclamp.min=256 uclamp.max=768

  $ cat /proc/$PID/sched | grep uclamp
  uclamp.min                                   :                  256
  uclamp.max                                   :                  768
  effective uclamp.min                         :                  256
  effective uclamp.max                         :                  512


Minor print nit below, otherwise:
Tested-and-reviewed-by: Valentin Schneider <valentin.schneider@....com>

Peter/Ingo, any chance this can go to sched/urgent? I know it's a debug
interface, but I'd rather have it land in a shape that makes sense. Again,
apologies for the goof.

> ---
>  kernel/sched/debug.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index a562df5..239970b 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -948,8 +948,8 @@ void proc_sched_show_task(struct task_struct *p, struct pid_namespace *ns,
>       P(se.avg.util_est.enqueued);
>  #endif
>  #ifdef CONFIG_UCLAMP_TASK
> -	__PS("uclamp.min", p->uclamp[UCLAMP_MIN].value);
> -	__PS("uclamp.max", p->uclamp[UCLAMP_MAX].value);
> +	__PS("uclamp.min", p->uclamp_req[UCLAMP_MIN].value);
> +	__PS("uclamp.max", p->uclamp_req[UCLAMP_MAX].value);

While we're at it, I'd prepend this with "requested".

>       __PS("effective uclamp.min", uclamp_eff_value(p, UCLAMP_MIN));
>       __PS("effective uclamp.max", uclamp_eff_value(p, UCLAMP_MAX));
>  #endif