[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250917192205.2306162-1-sieberf@amazon.com>
Date: Wed, 17 Sep 2025 21:22:05 +0200
From: Fernand Sieber <sieberf@...zon.com>
To: <peterz@...radead.org>
CC: <sieberf@...zon.com>, <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
Hi Peter,
I noticed you have pulled the change in sched/urgent.
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=78f8764d34c0a1912ce209bb2a428a94d062707f
However, I'd appreciate if you could weigh in on my concern regarding this
iteration not working well with core scheduling. Since the scheduler prefers to
run the yielding task again regardless of its eligibility rather than putting
the task in force idle, it can cause the yielding task vruntime to runaway
quickly. This scenario causes severe run delays later on. Please see my
previous reply with data supporting this concern. I think, the best approach to
address it would be to clamp vruntime. I'm not sure how exactly, a simple
approach would be to increment the vruntime by one slice until the task becomes
ineligible, if you have any suggestions let me know. I'll run some testing soon
when I get a chance.
Thanks, Fernand
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