From: David Laight <david.laight.linux@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kuba Piecuch <jpiecuch@google.com>,
mingo@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, joshdon@google.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] sched: add ability to throttle sched_yield() calls to reduce contention
Date: Sun, 17 Aug 2025 15:29:09 +0100 [thread overview]
Message-ID: <20250817152909.45567727@pumpkin> (raw)
In-Reply-To: <20250814145308.GB4067720@noisy.programming.kicks-ass.net>
On Thu, 14 Aug 2025 16:53:08 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, Aug 11, 2025 at 03:35:35PM +0200, Kuba Piecuch wrote:
> > On Mon, Aug 11, 2025 at 10:36 AM Peter Zijlstra <peterz@infradead.org> wrote:
...
> > The code calling sched_yield() was in the wait loop for a spinlock. It
> > would repeatedly yield until the compare-and-swap instruction succeeded
> > in acquiring the lock. This code runs in the SIGPROF handler.
>
> Well, then don't do that... userspace spinlocks are terrible, and
> bashing yield like that isn't helpful either.
All it takes is the kernel to take a hardware interrupt while your
'spin lock' is held and any other thread trying to acquire the
lock will sit at 100% cpu until all the interrupt work finishes.
A typical ethernet interrupt will schedule more work from a softint
context, with non-threaded napi you have to wait for that to finish.
That can all take milliseconds.
The same is true for a futex based lock - but at least the waiting
threads sleep.
Pretty much the only solution it to replace the userspace locks with
atomic operations (and hope the atomics make progress).
I'm pretty sure it only makes sense to have spin locks that disable
interrupts.
David
next prev parent reply other threads:[~2025-08-17 14:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 20:02 [RFC PATCH 0/3] sched: add ability to throttle sched_yield() calls to reduce contention Kuba Piecuch
2025-08-08 20:02 ` [RFC PATCH 1/3] sched: add bool return value to sched_class::yield_task() Kuba Piecuch
2025-08-08 20:02 ` [RFC PATCH 2/3] sched/fair: don't schedule() in yield if nr_running == 1 Kuba Piecuch
2025-08-08 20:02 ` [RFC PATCH 3/3] sched/fair: add debugfs knob for yield throttling Kuba Piecuch
2025-08-11 8:36 ` [RFC PATCH 0/3] sched: add ability to throttle sched_yield() calls to reduce contention Peter Zijlstra
2025-08-11 13:35 ` Kuba Piecuch
2025-08-14 14:53 ` Peter Zijlstra
2025-08-17 14:29 ` David Laight [this message]
2025-08-19 14:08 ` Kuba Piecuch
2025-08-20 15:49 ` Kuba Piecuch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250817152909.45567727@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=joshdon@google.com \
--cc=jpiecuch@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox