mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	kprateek.nayak@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: Fix flat hierarchy
Date: Fri, 14 Aug 2026 13:22:22 +0200	[thread overview]
Message-ID: <20260814112222.GY687043@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtDH4dcNf4DwcAzdDZ0i7w0Z7fK=7Tx776r8hJrdKC39pw@mail.gmail.com>

On Fri, Aug 14, 2026 at 11:26:13AM +0200, Vincent Guittot wrote:

> For the enqueue, the 1st requeue_delayed_entity() which is the main
> path for delayed task, requires the update. Then another one before
> reweight_eevdf(cfs_rq, se, weight, false); in the !curr case.
> 
> But I'm not sure we want to spread this in different places.

Fair enough. I'll test the below and then push to sched/urgent.

---
Subject: sched/fair: Fix flat hierarchy
From: Vincent Guittot <vincent.guittot@linaro.org>
Date: Wed, 12 Aug 2026 14:50:39 +0200

From: Vincent Guittot <vincent.guittot@linaro.org>

When a fair task is enqueued, we must update curr and more precisely
its vruntime before placing the enqueued task so avg vruntime will take
into account the last exec phase.

Example:
TA is an always running task in cgroup G0.
TB is a short running task (cyclictest) in cgroup G1.
The lag of TB always increases up the clamp limit because TB is placed
before TA(curr) is updated (since the last tick). When curr(TA) is
finally updated, its last exec phase provide positive lag to TB

Because TA and TB don't belong to the same group, enqueue_hierarchy() will not
update TA's entity when updating curr but only G0's entity at root level.

The same applies when dequeuing.

This is because update_curr() uses ->h_curr, rather than ->curr, and therefore,
while it is invoked on the root cfs_rq, which contains all the eevdf bits, it
does not do the right thing.

Fixes: 85570f10a4c6 ("sched/eevdf: Move to a single runqueue")
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260812125039.1717249-1-vincent.guittot@linaro.org
---
 kernel/sched/fair.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7958,6 +7958,15 @@ static unsigned long enqueue_hierarchy(s
 	return weight;
 }
 
+/* Update curr's vruntime before placing entity or updating lag */
+static inline void update_curr_eevdf(struct cfs_rq *cfs_rq)
+{
+	if (!cfs_rq->curr)
+		return;
+
+	update_curr(cfs_rq_of(cfs_rq->curr));
+}
+
 /*
  * The enqueue_task method is called before nr_running is
  * increased. Here we update the fair scheduling stats and
@@ -7985,6 +7994,8 @@ enqueue_task_fair(struct rq *rq, struct
 	if (!p->se.sched_delayed || (flags & ENQUEUE_DELAYED))
 		util_est_enqueue(cfs_rq, p);
 
+	update_curr_eevdf(cfs_rq);
+
 	if (flags & ENQUEUE_DELAYED) {
 		requeue_delayed_entity(cfs_rq, se);
 		return;
@@ -8105,7 +8116,7 @@ static bool __dequeue_task(struct rq *rq
 
 	clear_buddies(cfs_rq, se);
 
-	update_curr(cfs_rq_of(se));
+	update_curr_eevdf(cfs_rq);
 	update_entity_lag(cfs_rq, se);
 
 	if (flags & DEQUEUE_DELAYED) {

  reply	other threads:[~2026-08-14 11:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 12:50 Vincent Guittot
2026-08-12 14:03 ` Peter Zijlstra
2026-08-12 14:21   ` Vincent Guittot
2026-08-13 10:31     ` Peter Zijlstra
2026-08-13 10:49       ` Vincent Guittot
2026-08-14  9:26         ` Vincent Guittot
2026-08-14 11:22           ` Peter Zijlstra [this message]
2026-08-14 12:51             ` Vincent Guittot
2026-08-14 14:16               ` Peter Zijlstra
2026-08-14 14:31                 ` Vincent Guittot
2026-08-14 19:35 ` [tip: sched/core] " tip-bot2 for Vincent Guittot

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=20260814112222.GY687043@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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®