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 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.