All of lore.kernel.org
 help / color / mirror / Atom feed
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

[...]

  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 [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 [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 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.