[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240604101107.GO26599@noisy.programming.kicks-ass.net>
Date: Tue, 4 Jun 2024 12:11:07 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Luis Machado <luis.machado@....com>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
linux-kernel@...r.kernel.org, kprateek.nayak@....com,
wuyun.abel@...edance.com, tglx@...utronix.de, efault@....de,
nd <nd@....com>, John Stultz <jstultz@...gle.com>,
Hongyan.Xia2@....com
Subject: Re: [RFC][PATCH 08/10] sched/fair: Implement delayed dequeue
On Mon, Jun 03, 2024 at 08:30:43PM +0100, Luis Machado wrote:
> Exchanging some information with Hongyan today, he was a bit suspicious of the uclamp
> behavior with the eevdf complete series applied.
>
> Checking the uclamp code, I see we have some refcounting tied to enqueuing/dequeuing
> of tasks, and the uclamp values are organized in buckets.
>
> Just for fun I added a few trace_printk's in uclamp_eff_value, uclamp_rq_inc_id and
> uclamp_rq_dec_id.
>
> Booting up the system with delayed_dequeue disabled and running the benchmark, I
> see the uclamp bucket management pretty stable. Tasks get added to the uclamp
> buckets but then get removed. At the end of the benchmark, the uclamp buckets
> are (almost always) clean of tasks.
>
> Enabling delayed dequeue, I can see the uclamp buckets slowly filling up with
> tasks. At the end of the benchmark, I see uclamp buckets with 30, 40 or 50
> tasks still. If I do another run, I can see 80, 100 tasks still.
>
> I suspect refcounting might be going wrong somewhere due to delayed dequeue
> tasks, but that's more of a guess right now. Hopefully that is useful
> information. I'll resume investigation tomorrow.
Thank you both!!
Does the below help?
Note how dequeue_task() does uclamp_rq_dec() unconditionally, which is
then not balanced in the case below.
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3664,6 +3664,7 @@ static int ttwu_runnable(struct task_str
/* mustn't run a delayed task */
SCHED_WARN_ON(task_on_cpu(rq, p));
enqueue_task(rq, p, ENQUEUE_DELAYED);
+ uclamp_rq_inc(rq, p);
}
if (!task_on_cpu(rq, p)) {
/*
Powered by blists - more mailing lists