From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
Xuewen Yan <xuewen.yan94@gmail.com>
Cc: Xuewen Yan <xuewen.yan@unisoc.com>,
mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
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
Subject: Re: [PATCH v2] sched/uclamp: Align uclamp and util_est and call before freq update
Date: Thu, 17 Apr 2025 00:12:20 +0200 [thread overview]
Message-ID: <acef778c-a359-484d-a61d-aeca81bdae1d@arm.com> (raw)
In-Reply-To: <CAKfTPtC2XA_DUy5zjPo4Xr1r7W-CFiZEwabEQcZPk0FDLxc3QQ@mail.gmail.com>
On 16/04/2025 14:19, Vincent Guittot wrote:
> On Wed, 16 Apr 2025 at 13:07, Xuewen Yan <xuewen.yan94@gmail.com> wrote:
>>
>> On Wed, Apr 16, 2025 at 5:42 PM Vincent Guittot
>> <vincent.guittot@linaro.org> wrote:
>>>
>>> On Wed, 16 Apr 2025 at 04:55, Xuewen Yan <xuewen.yan94@gmail.com> wrote:
>>>>
>>>> On Wed, Apr 16, 2025 at 1:05 AM Vincent Guittot
>>>> <vincent.guittot@linaro.org> wrote:
>>>>>
>>>>> On Tue, 25 Mar 2025 at 02:48, Xuewen Yan <xuewen.yan@unisoc.com> wrote:
[...]
>>> Why is testing sched_delayed enough for migrating/prio_change ?
>>> With your change, we will remove then add back util_est when changing
>>> prio of the task which is useless
>>
>> I sincerely apologize for any misunderstanding my previous description
>> may have caused.
>> When changing prio without changing class, the delayed_task's
>> sched_delayed flag is not changed,
>> we would not remove then add back util_est.
>> If the class was changed:
>>
>> if (prev_class != next_class && p->se.sched_delayed)
>> dequeue_task(rq, p, DEQUEUE_SLEEP | DEQUEUE_DELAYED |
>> DEQUEUE_NOCLOCK);
>>
>> It will dequeue the delayed-task first, and will not enqueue it.
>>
>> As for normal tasks which are not delayed, indeed, the issue you
>> mentioned can occur, but it seems that this problem has always
>> existed. Perhaps this is a new issue that has come up.
>
> I have been confused by the patch that added the condition "if
> (!(p->se.sched_delayed && (task_on_rq_migrating(p) || (flags &
> ENQUEUE_RESTORE))))". I wrongly thought it was for
> dequeue_save/enqueue_restore
No, this was just for sched_delayed. I convinced myself that the
logic stays the same with the following tests:
-->8--
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index eb5a2572b4f8..65692938696f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6930,6 +6930,19 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
int rq_h_nr_queued = rq->cfs.h_nr_queued;
u64 slice = 0;
+ bool D = !!p->se.sched_delayed;
+ bool M = task_on_rq_migrating(p);
+ bool Er = !!(flags & ENQUEUE_RESTORE);
+ bool Ed = !!(flags & ENQUEUE_DELAYED);
+
+ /* won't be called */
+ BUG_ON(D && M && Er); // [1]
+ BUG_ON(!D && M && Er); // [2]
+
+ BUG_ON(D && ((M || Er) == Ed)); // [3]
+ BUG_ON(!(D && (M || Er)) != (!D || Ed)); // [4]
+ BUG_ON(!(D && (M || Er)) != (!(D && !Ed)));
+
/*
* The code below (indirectly) updates schedutil which looks at
* the cfs_rq utilization to select a frequency.
@@ -7178,6 +7191,17 @@ 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)
{
+ bool D = !!p->se.sched_delayed;
+ bool M = task_on_rq_migrating(p);
+ bool Ds = !!(flags & DEQUEUE_SAVE);
+
+ /* won't be called */
+ BUG_ON(D && M && Ds); // [5]
+ BUG_ON(!D && M && Ds); // [6]
+ BUG_ON(D && !M && !Ds); // [7]
+
+ BUG_ON(!(D && (M || Ds)) != !D); // [8]
+
if (!(p->se.sched_delayed && (task_on_rq_migrating(p) || (flags & DEQUEUE_SAVE))))
util_est_dequeue(&rq->cfs, p);
-->8--
In enqueue, when D is true, M or Er is never set with Ed. [3], [4].
In dequeue, since [7] is never true, [8] is never true as well.
> Could you please split this in 2 patches :
> patch 1 updates condition for util_est_dequeue/enqueue and a
> description why it's safe
> patch 2 for aligning uclamp with util_est
+1
[...]
next prev parent reply other threads:[~2025-04-16 22:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 1:47 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 [this message]
2025-04-17 1:39 ` Xuewen Yan
2025-04-16 6:38 ` Kuyo Chang
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=acef778c-a359-484d-a61d-aeca81bdae1d@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bsegall@google.com \
--cc=di.shen@unisoc.com \
--cc=hongyan.xia2@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®