From: Peter Zijlstra <peterz@infradead.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Arnd Bergmann <arnd@arndb.de>, Ingo Molnar <mingo@elte.hu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tony Breeds <tonyb@au1.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH/RFC] mutex: Fix optimistic spinning vs. BKL
Date: Mon, 10 May 2010 09:55:59 +0200 [thread overview]
Message-ID: <1273478159.5605.3324.camel@twins> (raw)
In-Reply-To: <1273271262.4861.134.camel@pasglop>
On Sat, 2010-05-08 at 08:27 +1000, Benjamin Herrenschmidt wrote:
> > Also, to solve this problem when several cpus may spin on the owner,
> > I wonder adaptive spinning is doing the right thing here. We should
> > have only one spinner I think, and the rest should go to sleep as the
> > time to spin on several subsequent owners would be much better gained
> > to do something else (schedule something else or power saving).
> > In fact, that too could deserve some tests.
>
> Right, the problem is due to the fact that we skip spinning if there's
> already a waiter but we don't know that there is already a spinner so we
> can end up with multiple spinners.
>
> I don't see a non invasive way to fix that.. we could add a spinner
> counter to the mutex but that sucks a bit. Might still be worthwhile,
> not sure. Peter, what do you reckon ?
If its a large problem the lock is overly contended and _that_ needs
fixing. I don't at all feel like adding atomic ops to the spin loop to
try and detect this.
As to the 2 jiffy spin timeout, I guess we should add a lockdep warning
for that, because anybody holding a mutex for longer than 2 jiffies and
not sleeping does need fixing anyway.
next prev parent reply other threads:[~2010-05-10 7:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 4:38 [PATCH/RFC] mutex: Fix optimistic spinning vs. BKL Benjamin Herrenschmidt
2010-04-28 4:39 ` Benjamin Herrenschmidt
2010-04-28 12:06 ` Arnd Bergmann
2010-04-28 22:35 ` Benjamin Herrenschmidt
2010-05-07 4:20 ` Tony Breeds
2010-05-07 5:30 ` Frederic Weisbecker
2010-05-07 6:01 ` Benjamin Herrenschmidt
2010-05-07 21:29 ` Frederic Weisbecker
2010-05-07 22:27 ` Benjamin Herrenschmidt
2010-05-10 7:55 ` Peter Zijlstra [this message]
2010-05-11 18:06 ` Linus Torvalds
2010-05-11 18:19 ` Peter Zijlstra
2010-05-11 21:13 ` Benjamin Herrenschmidt
2010-05-07 6:16 ` Mike Galbraith
2010-05-11 15:43 ` [tip:core/locking] " tip-bot for Tony Breeds
2010-05-11 23:05 ` Tony Breeds
2010-05-18 16:08 ` Ingo Molnar
2010-05-18 16:26 ` Linus Torvalds
2010-05-19 5:46 ` Tony Breeds
2010-05-19 7:56 ` [tip:core/urgent] " tip-bot for Tony Breeds
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=1273478159.5605.3324.camel@twins \
--to=peterz@infradead.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tonyb@au1.ibm.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.