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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 May 2020 07:25:47 +0530 From: Pavan Kondeti <pkondeti@...eaurora.org> To: Valentin Schneider <valentin.schneider@....com> 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 Sun, May 10, 2020 at 05:16:28PM +0100, Valentin Schneider wrote: > > 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 Thanks Valentin for taking a look. I have added "requested" prefix and sent the patch. Thanks, Pavan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists