As described in commit b07996c7abac ("sched_ext: Don't hold
scx_tasks_lock for too long"), we're doing a cond_resched() every 32
calls to scx_task_iter_next() to avoid RCU and other stalls. That commit
also added a cpu_relax() to the codepath where we drop and reacquire the
lock, but as Waiman described in [0], cpu_relax() should only be
necessary in busy loops to avoid pounding on a cacheline (or to allow a
hypertwin to more fully utilize a core).

Let's remove the unnecessary cpu_relax().

[0]: https://lore.kernel.org/all/35b3889b-904a-4d26-981f-c8aa1557a7c7@redhat.com/

Cc: Waiman Long <llong@redhat.com>
Signed-off-by: David Vernet <void@manifault.com>
---
 kernel/sched/ext.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index cb1ab668e965..6eae3b69bf6e 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -1374,7 +1374,6 @@ static struct task_struct *scx_task_iter_next(struct scx_task_iter *iter)
 
 	if (!(++iter->cnt % SCX_OPS_TASK_ITER_BATCH)) {
 		scx_task_iter_unlock(iter);
-		cpu_relax();
 		cond_resched();
 		scx_task_iter_relock(iter);
 	}
-- 
2.46.1

On Mon, Oct 14, 2024 at 12:58:30PM -0500, David Vernet wrote:
> As described in commit b07996c7abac ("sched_ext: Don't hold
> scx_tasks_lock for too long"), we're doing a cond_resched() every 32
> calls to scx_task_iter_next() to avoid RCU and other stalls. That commit
> also added a cpu_relax() to the codepath where we drop and reacquire the
> lock, but as Waiman described in [0], cpu_relax() should only be
> necessary in busy loops to avoid pounding on a cacheline (or to allow a
> hypertwin to more fully utilize a core).
> 
> Let's remove the unnecessary cpu_relax().
> 
> [0]: https://lore.kernel.org/all/35b3889b-904a-4d26-981f-c8aa1557a7c7@redhat.com/
> 
> Cc: Waiman Long <llong@redhat.com>
> Signed-off-by: David Vernet <void@manifault.com>

Applied to sched_ext/for-6.12-fixes.

Thanks.

-- 
tejun