From: Peter Zijlstra <peterz@infradead.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Xuewen Yan <xuewen.yan94@gmail.com>,
valentin.schneider@arm.com, mingo@redhat.com,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
linux-kernel@vger.kernel.org, patrick.bellasi@matbug.net,
qperret@google.com
Subject: Re: [PATCH v2] sched/uclamp: Avoid getting unreasonable ucalmp value when rq is idle
Date: Fri, 2 Jul 2021 14:00:29 +0200 [thread overview]
Message-ID: <YN7/3RkISFqM4rt+@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210702115421.gcju2vluhof6rp6f@e107158-lin.cambridge.arm.com>
On Fri, Jul 02, 2021 at 12:54:21PM +0100, Qais Yousef wrote:
> Yep. How about the below?
>
> --->8---
>
> sched/uclamp: Ignore max aggregation if rq is idle
>
> When a task wakes up on an idle rq, uclamp_rq_util_with() would max
> aggregate with rq value. But since there is no task enqueued yet, the
> values are stale based on the last task that was running. When the new
> task actually wakes up and enqueued, then the rq uclamp values should
> reflect that of the newly woken up task effective uclamp values.
>
> This is a problem particularly for uclamp_max because it default to
> 1024. If a task p with uclamp_max = 512 wakes up, then max aggregation
> would ignore the capping that should apply when this task is enqueued,
> which is wrong.
>
> Fix that by ignoring max aggregation if the rq is idle since in that
> case the effective uclamp value of the rq will be the ones of the task
> that will wake up.
>
> --->8---
Much better, I've updated it. Thanks!
next prev parent reply other threads:[~2021-07-02 12:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 14:12 [PATCH v2] sched/uclamp: Avoid getting unreasonable ucalmp value when rq is idle Xuewen Yan
2021-06-30 14:24 ` Valentin Schneider
2021-07-01 11:32 ` Qais Yousef
2021-07-02 11:12 ` Peter Zijlstra
2021-07-02 11:54 ` Qais Yousef
2021-07-02 12:00 ` Peter Zijlstra [this message]
2021-07-02 12:12 ` Valentin Schneider
2021-07-02 13:03 ` Xuewen Yan
2021-07-05 7:53 ` [tip: sched/urgent] sched/uclamp: Ignore max aggregation if " tip-bot2 for Xuewen Yan
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=YN7/3RkISFqM4rt+@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--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=qais.yousef@arm.com \
--cc=qperret@google.com \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=xuewen.yan94@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.