[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250918064300.GV3419281@noisy.programming.kicks-ass.net>
Date: Thu, 18 Sep 2025 08:43:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Fernand Sieber <sieberf@...zon.com>
Cc: bsegall@...gle.com, dietmar.eggemann@....com, dwmw@...zon.co.uk,
graf@...zon.com, jschoenh@...zon.de, juri.lelli@...hat.com,
linux-kernel@...r.kernel.org, mingo@...hat.com,
tanghui20@...wei.com, vincent.guittot@...aro.org,
vineethr@...ux.ibm.com, wangtao554@...wei.com,
zhangqiao22@...wei.com
Subject: Re: [PATCH v2] sched/fair: Forfeit vruntime on yield
On Tue, Sep 16, 2025 at 06:00:35PM +0200, Fernand Sieber wrote:
> After further testing I think we should stick with the original approach or
> iterate on the vruntime forfeiting.
>
> The vruntime forfeiting doesn't work well with core scheduling. The core
> scheduler picks the best task across the SMT mask, and then the siblings run a
> matching task no matter what. This means the core scheduler can keep picking
> the yielding task on the sibling even after it becomes ineligible (because it's
> preferrable than force idle). In this scenario the vruntime of the yielding
> task runs away rapidly, which causes problematic imbalances later on.
>
> Perhaps an alternative is to forfeit the vruntime (set it to the deadline), but
> only once. I.e don't do it if the task is already ineligible? If the task is
> ineligible then we simply increment the deadline as in my original patch?
>
> Peter, let me know your thoughts on this.
Sorry, I missed this email earlier. I'll go ponder it a bit -- my brain
is esp. slow today due to a cold :/
Powered by blists - more mailing lists