From: Kuyo Chang <kuyo.chang@mediatek.com>
To: Xuewen Yan <xuewen.yan@unisoc.com>, <dietmar.eggemann@arm.com>,
<mingo@redhat.com>, <peterz@infradead.org>,
<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>
Cc: rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, hongyan.xia2@arm.com, qyousef@layalina.io,
ke.wang@unisoc.com, di.shen@unisoc.com,
linux-kernel@vger.kernel.org, xuewen.yan94@gmail.com,
"建均 宋" <juju.sung@mediatek.com>
Subject: Re: [PATCH v2] sched/uclamp: Align uclamp and util_est and call before freq update
Date: Wed, 16 Apr 2025 14:38:54 +0800 [thread overview]
Message-ID: <813901445537b9a2fed9854ca8f91b46d3845346.camel@mediatek.com> (raw)
In-Reply-To: <20250325014733.18405-1-xuewen.yan@unisoc.com>
On Tue, 2025-03-25 at 09:47 +0800, Xuewen Yan wrote:
> When task's uclamp is set, we hope that the CPU frequency
> can increase as quickly as possible when the task is enqueued.
> Because the cpu frequency updating happens during the enqueue_task(),
> so the rq's uclamp needs to be updated before the task is enqueued,
> just like util_est.
> So, aline the uclamp and util_est and call before freq update.
>
> For sched-delayed tasks, the rq uclamp/util_est should only be
> updated
> when they are enqueued upon being awakened.
> So simply the logic of util_est's enqueue/dequeue check.
>
> Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
> ---
> v2:
> - simply the util-est's en/dequeue check;
> ---
> Previous discussion:
> https://lore.kernel.org/all/CAB8ipk8pEvOtCm-d0o1rsekwxPWUHk9iBGtt9TLTWW-iWTQKiA@mail.gmail.com/
> https://lore.kernel.org/all/84441660bef0a5e67fd09dc3787178d0276dad31.1740664400.git.hongyan.xia2@arm.com/T/#u
> https://lore.kernel.org/all/CAB8ipk9LpbiUDnbcV6+59+Sa=Ai7tFzO===mpLD3obNdV4=J-A@mail.gmail.com/T/#u
> https://lore.kernel.org/all/aa8baf67-a8ec-4ad8-a6a8-afdcd7036771@arm.com/
> ---
> kernel/sched/core.c | 17 ++++++++++-------
> kernel/sched/fair.c | 4 ++--
> 2 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 042351c7afce..72fbe2031e54 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1747,7 +1747,7 @@ static inline void uclamp_rq_dec_id(struct rq
> *rq, struct task_struct *p,
> }
> }
>
> -static inline void uclamp_rq_inc(struct rq *rq, struct task_struct
> *p)
> +static inline void uclamp_rq_inc(struct rq *rq, struct task_struct
> *p, int flags)
> {
> enum uclamp_id clamp_id;
>
> @@ -1763,7 +1763,8 @@ static inline void uclamp_rq_inc(struct rq *rq,
> struct task_struct *p)
> if (unlikely(!p->sched_class->uclamp_enabled))
> return;
>
> - if (p->se.sched_delayed)
> + /* Only inc the delayed task which being woken up. */
> + if (p->se.sched_delayed && !(flags & ENQUEUE_DELAYED))
> return;
>
> for_each_clamp_id(clamp_id)
> @@ -2031,7 +2032,7 @@ static void __init init_uclamp(void)
> }
>
> #else /* !CONFIG_UCLAMP_TASK */
> -static inline void uclamp_rq_inc(struct rq *rq, struct task_struct
> *p) { }
> +static inline void uclamp_rq_inc(struct rq *rq, struct task_struct
> *p, int flags) { }
> static inline void uclamp_rq_dec(struct rq *rq, struct task_struct
> *p) { }
> static inline void uclamp_fork(struct task_struct *p) { }
> static inline void uclamp_post_fork(struct task_struct *p) { }
> @@ -2067,12 +2068,14 @@ void enqueue_task(struct rq *rq, struct
> task_struct *p, int flags)
> if (!(flags & ENQUEUE_NOCLOCK))
> update_rq_clock(rq);
>
> - p->sched_class->enqueue_task(rq, p, flags);
> /*
> - * Must be after ->enqueue_task() because ENQUEUE_DELAYED
> can clear
> - * ->sched_delayed.
> + * Can be before ->enqueue_task() because uclamp considers
> the
> + * ENQUEUE_DELAYED task before its ->sched_delayed gets
> cleared
> + * in ->enqueue_task().
> */
> - uclamp_rq_inc(rq, p);
> + uclamp_rq_inc(rq, p, flags);
> +
> + p->sched_class->enqueue_task(rq, p, flags);
>
> psi_enqueue(p, flags);
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index c798d2795243..c92fee07fb7b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6930,7 +6930,7 @@ enqueue_task_fair(struct rq *rq, struct
> task_struct *p, int flags)
> * Let's add the task's estimated utilization to the
> cfs_rq's
> * estimated utilization, before we update schedutil.
> */
> - if (!(p->se.sched_delayed && (task_on_rq_migrating(p) ||
> (flags & ENQUEUE_RESTORE))))
> + if (!p->se.sched_delayed || (flags & ENQUEUE_DELAYED))
> util_est_enqueue(&rq->cfs, p);
>
> if (flags & ENQUEUE_DELAYED) {
> @@ -7168,7 +7168,7 @@ static int dequeue_entities(struct rq *rq,
> struct sched_entity *se, int flags)
> */
> static bool dequeue_task_fair(struct rq *rq, struct task_struct *p,
> int flags)
> {
> - if (!(p->se.sched_delayed && (task_on_rq_migrating(p) ||
> (flags & DEQUEUE_SAVE))))
> + if (!p->se.sched_delayed)
> util_est_dequeue(&rq->cfs, p);
>
> util_est_update(&rq->cfs, p, flags & DEQUEUE_SLEEP);
The HW composer detects the frame status and uses uclamp to adjust the
CPU frequency for specific tasks.
After applying this patch, there is a significant improvement in the
performance of the dispatch system.
==================================================================
Test : FHD(1920x1080) video playback 30fps in 60hz frame rate.
Units : jank(frame drop)
Interpretation: lower is better
Statistic : AMean in one minutes
==================================================================
asis with patch
6-janks 0-janks
prev parent reply other threads:[~2025-04-16 6:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 1:47 [PATCH v2] sched/uclamp: Align uclamp and util_est and call before freq update Xuewen Yan
2025-03-25 16:54 ` K Prateek Nayak
2025-03-26 2:57 ` Xuewen Yan
2025-03-26 4:37 ` K Prateek Nayak
2025-03-26 11:46 ` Xuewen Yan
2025-04-01 8:31 ` Dietmar Eggemann
2025-04-01 8:32 ` Dietmar Eggemann
2025-04-15 17:04 ` Vincent Guittot
2025-04-16 2:55 ` Xuewen Yan
2025-04-16 9:42 ` Vincent Guittot
2025-04-16 11:07 ` Xuewen Yan
2025-04-16 12:19 ` Vincent Guittot
2025-04-16 22:12 ` Dietmar Eggemann
2025-04-17 1:39 ` Xuewen Yan
2025-04-16 6:38 ` Kuyo Chang [this message]
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=813901445537b9a2fed9854ca8f91b46d3845346.camel@mediatek.com \
--to=kuyo.chang@mediatek.com \
--cc=bsegall@google.com \
--cc=di.shen@unisoc.com \
--cc=dietmar.eggemann@arm.com \
--cc=hongyan.xia2@arm.com \
--cc=juju.sung@mediatek.com \
--cc=juri.lelli@redhat.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.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.