From: Miquel van Smoorenburg <miquels@cistron.nl>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, miquels@cistron.nl
Subject: spinlock which can morph into a mutex
Date: Fri, 18 Dec 2009 15:30:35 +0100 [thread overview]
Message-ID: <20091218143032.GA16595@xs4all.net> (raw)
I'm trying to implement a dynamically resizable hashtable, and
I have found that after resizing the table I need to call
synchronize_rcu() and finish up before letting other writers
(inserts, deletes) access the table.
Ofcourse during the hashtable update a spinlock is held to
exclude the other writers. But I cannot hold this spinlock over
synchronize_rcu(), yet the other writers still need to be excluded.
So I probably need a mutex instead of a spinlock, but I want to
keep minimal overhead for the common case (when no resizing is in
progress). I think I need a spinlock that can morph into a mutex ..
I was thinking about using something like the code below.
It is sortof like a spinlock, but it's ofcourse less fair
than actual ticketed spinlocks.
I'm working off 2.6.27 at the moment, but I noticed that in
2.6.28 adaptive spinning was introduced for mutexes. Is the
approach below still worth it with adaptive spinning or could
I just convert the spinlocks to mutexes with minimal extra overhead ?
Example code:
int real_mutex_lock = 0; // can use int since mutex ops are barriers
struct mutex mutex;
// 1. used instead of spinlock() [common case]
while (mutex_trylock(&mutex) == 0) {
if (real_mutex_lock) {
mutex_lock(&mutex);
break;
}
}
.. have lock, do work
mutex_unlock(&mutex);
// 2. When we want to lock and be able to sleep [seldomly used]
mutex_lock(&mutex);
real_mutex_lock = 1;
smp_wmb();
.. do work ..
real_mutex_lock = 0;
mutex_unlock(&mutex);
Mike.
next reply other threads:[~2009-12-18 14:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-18 14:30 Miquel van Smoorenburg [this message]
2009-12-18 15:26 ` spinlock which can morph into a mutex Andi Kleen
2009-12-18 15:43 ` Peter Zijlstra
2009-12-18 17:14 ` Thomas Gleixner
2009-12-18 18:19 ` Miquel van Smoorenburg
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=20091218143032.GA16595@xs4all.net \
--to=miquels@cistron.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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