From: Valentin Schneider <valentin.schneider@arm.com>
To: Pavankumar Kondeti <pkondeti@codeaurora.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Qais Yousef <qais.yousef@arm.com>
Subject: Re: [PATCH] sched/debug: Fix requested task uclamp values shown in procfs
Date: Sun, 10 May 2020 17:16:28 +0100 [thread overview]
Message-ID: <jhjblmvu5nn.mognet@arm.com> (raw)
In-Reply-To: <1589115401-26391-1-git-send-email-pkondeti@codeaurora.org>
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@codeaurora.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@arm.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
next prev parent reply other threads:[~2020-05-10 16:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-10 12:56 [PATCH] sched/debug: Fix requested task uclamp values shown in procfs Pavankumar Kondeti
2020-05-10 16:16 ` Valentin Schneider [this message]
2020-05-11 1:55 ` Pavan Kondeti
2020-05-19 18:44 ` [tip: sched/urgent] " tip-bot2 for Pavankumar Kondeti
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=jhjblmvu5nn.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.