From: Valentin Schneider <valentin.schneider@arm.com>
To: Xuewen Yan <xuewen.yan94@gmail.com>
Cc: 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>,
Benjamin Segall <bsegall@google.com>,
Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Chunyan Zhang <zhang.lyra@gmail.com>,
Quentin Perret <qperret@google.com>,
Qais Yousef <qais.yousef@arm.com>
Subject: Re: [PATCH] sched/uclamp: Fix getting unreasonable ucalmp_max when rq is idle
Date: Wed, 30 Jun 2021 12:31:45 +0100 [thread overview]
Message-ID: <87czs38u72.mognet@arm.com> (raw)
In-Reply-To: <CAB8ipk9TMTbw2WGrbLuewk_CaYxrvMOp2Ui5xiHiwYB4NmoRhA@mail.gmail.com>
On 30/06/21 09:24, Xuewen Yan wrote:
> On Tue, Jun 29, 2021 at 9:50 PM Valentin Schneider
> <valentin.schneider@arm.com> wrote:
>> + min_util = max_t(unsigned long, min_util, READ_ONCE(rq->uclamp[UCLAMP_MIN].value));
>> + max_util = max_t(unsigned long, max_util, READ_ONCE(rq->uclamp[UCLAMP_MAX].value));
>
> Is it necessary to use max_t here? although it is not the main problem...
>
I got comparison warnings when using a regular max() - the RQ clamp values
are unsigned int, whereas the local variable is unsigned long.
>> +out:
>> /*
>> * Since CPU's {min,max}_util clamps are MAX aggregated considering
>> * RUNNABLE tasks with _different_ clamps, we can end up with an
>
> Thanks!
> xuewen
next prev parent reply other threads:[~2021-06-30 11:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-18 7:23 [PATCH] sched/uclamp: Fix getting unreasonable ucalmp_max when rq is idle Xuewen Yan
2021-06-29 3:11 ` Xuewen Yan
2021-06-29 13:50 ` Valentin Schneider
2021-06-30 1:24 ` Xuewen Yan
2021-06-30 11:31 ` Valentin Schneider [this message]
2021-06-30 12:05 ` Xuewen Yan
2021-06-30 14:11 ` Qais Yousef
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=87czs38u72.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bristot@redhat.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=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=xuewen.yan94@gmail.com \
--cc=zhang.lyra@gmail.com \
/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.