From 467904416b3786c9f2b29ca683d36cb2523ae7ce Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Thu, 17 Oct 2024 16:29:50 +0100 Subject: [PATCH] handle sched_yield gracefully when being hammered Some misguided apps hammer sched_yield() in a tight loop (they should be using futexes instead) which causes massive lock contention even if there is little work to do or to yield to. rare limit yielding since the base scheduler does a pretty good job already about just running the right things Signed-off-by: Colin Ian King --- kernel/sched/syscalls.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c index ae1b42775ef9..441ac65f4f15 100644 --- a/kernel/sched/syscalls.c +++ b/kernel/sched/syscalls.c @@ -1456,10 +1456,22 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len, return ret; } +static DEFINE_PER_CPU(unsigned long, last_yield); + static void do_sched_yield(void) { struct rq_flags rf; struct rq *rq; + int cpu = raw_smp_processor_id(); + + cond_resched(); + + /* rate limit yielding to something sensible */ + + if (!time_after(jiffies, per_cpu(last_yield, cpu))) + return; + + per_cpu(last_yield, cpu) = jiffies; rq = this_rq_lock_irq(&rf); -- 2.46.2