Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1205864ybk; Sun, 10 May 2020 09:19:36 -0700 (PDT) X-Google-Smtp-Source: APiQypLollv6husS1MLAOgHdO/djqVQoMeAJ2PpkVFbmWTSEVUK6b5U/HokQ0o1Hqmv5l/iUHGL/ X-Received: by 2002:aa7:dcd7:: with SMTP id w23mr10442254edu.300.1589127576130; Sun, 10 May 2020 09:19:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589127576; cv=none; d=google.com; s=arc-20160816; b=tPpJySSgKGSSTXQrfqOJJkWgX0AtKnyI8ZeMWbKvMX3UaP/vfB7lYAauP3AuKMGGZ7 INi88yARpi4pqrwwRMGsughHt9zinuaOWmIYFEMPEILR1yNMGsp+fH96GL8yoo2i7PNR cio/gNonFmhpEbqyd2gI9sJrJ0Z0LB2eCtYvaphtX/wEy3ir3FnVN7MS5uvoI91BQM/2 wa/O29Ll4KWYR/iwC8sb5oTRgitVflP0wceDrpVYj/fI+kLPG+FBPoungJYw1GPkezdt DLZ72Q3RFkVFUOVco9/UMTbgAMBvxbC+gGRCbbeXNyrpmgl2kp4LRx4lq7OwOTNw9Nd1 MzKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=kgT6ffN2IlCN24Wbm9KbVWLwTm6BL7/G++/rRbliJI4=; b=RPMb1M7WYkeUp3MIqhrNna1B6BE7dIAHoz+hcynPgLuM1PR6MfRzScfO2IUy0G9Cgz mW/eUhORG9pNbzsydDRULWwxWHXs+3gpi0jEGITQ6NQA0aNLUckaIBCyMrzGCWUZRhWN QbKfeY0WDyEXewtaJRI1hcbM2YkH9Cr+KW77dJIIACj37dwbsstV5fNzXpb2pXPbMk8Y MzF94YgRk185AnPmbGgq0n/5Nsyq+lMvlz/yufftAvAx//ZSb1BcoHhO+HZLu33lwdlE C0re7AFzjj5o9ihokyNTgAVz5IW6TrxUnm+cDXKYudGQtALHrpHUxjDgsny3mzTZiKi4 04PA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o10si4358780edq.359.2020.05.10.09.18.58; Sun, 10 May 2020 09:19:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728866AbgEJQQg (ORCPT + 99 others); Sun, 10 May 2020 12:16:36 -0400 Received: from foss.arm.com ([217.140.110.172]:44344 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726446AbgEJQQg (ORCPT ); Sun, 10 May 2020 12:16:36 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 628E530E; Sun, 10 May 2020 09:16:35 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB6343F68F; Sun, 10 May 2020 09:16:33 -0700 (PDT) References: <1589115401-26391-1-git-send-email-pkondeti@codeaurora.org> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Pavankumar Kondeti Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Qais Yousef Subject: Re: [PATCH] sched/debug: Fix requested task uclamp values shown in procfs In-reply-to: <1589115401-26391-1-git-send-email-pkondeti@codeaurora.org> Date: Sun, 10 May 2020 17:16:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 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 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