[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250916133520.406318-1-sieberf@amazon.com>
Date: Tue, 16 Sep 2025 15:35:20 +0200
From: Fernand Sieber <sieberf@...zon.com>
To: <peterz@...radead.org>
CC: <bsegall@...gle.com>, <dietmar.eggemann@....com>, <graf@...zon.com>,
<juri.lelli@...hat.com>, <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
<sieberf@...zon.com>, <tanghui20@...wei.com>, <vincent.guittot@...aro.org>,
<vineethr@...ux.ibm.com>, <wangtao554@...wei.com>, <zhangqiao22@...wei.com>
Subject: Re: [PATCH RESEND] sched/fair: Only increment deadline once on yield
On Thu, Sep 11, 2025 at 01:37:46PM +0200, Peter Zijlstra wrote:
> Have you tried:
>
> se->vruntime = se->deadline;
> se->deadline += calc_delta_fair(se->slice, se);
>
> instead?
Thanks, that is better, see results below.
Forfeiting the vruntime allows competing tasks to make more progress.
Both approaches eliminate the problematic run delays.
I'll send out an updated version of the patch.
Repro:
taskset -c 1 yield_loop &
taskset -c 1 stress --cpu 1 --timeout 30s &
With yield loop:
int main() {
time_t start = time(NULL);
while (time(NULL) - start < 5) {
sched_yield();
}
while (1) {}
return 0;
}
Results (perf sched latency):
vanilla:
stress: 2368ms runtime, max delay 25268ms (!)
yield_loop: 27637ms runtime, max delay 2ms
deadline clamping:
stress: 4629ms runtime, max delay 2ms
yield_loop: 4632ms runtime, max delay 2ms
vruntime forfeiting:
stress: 7117ms runtime, max delay 2ms
yield_loop: 2144ms runtime, max delay 2ms
Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07
Powered by blists - more mailing lists