From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
RT <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Clark Williams <williams@redhat.com>
Subject: Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks
Date: Tue, 15 May 2012 17:06:23 +0200 [thread overview]
Message-ID: <1337094383.27694.62.camel@twins> (raw)
In-Reply-To: <1337090625.14207.304.camel@gandalf.stny.rr.com>
On Tue, 2012-05-15 at 10:03 -0400, Steven Rostedt wrote:
>
> where readers may nest (the same task may grab the same rwsem for
> read multiple times), but only one task may hold the rwsem at any
> given
> time (for read or write).
Humm, that sounds iffy, rwsem isn't a recursive read lock only rwlock_t
is.
> The idea here is to have an rwsem create a rt_mutex for each CPU.
> Actually, it creates a rwsem for each CPU that can only be acquired by
> one task at a time. This allows for readers on separate CPUs to take
> only the per cpu lock. When a writer needs to take a lock, it must
> grab
> all CPU locks before continuing.
So you've turned it into a global/local or br or whatever that thing was
called lock.
>
> Also, I don't use per_cpu sections for the locks, which means we have
> cache line collisions, but a normal (mainline) rwsem has that as well.
>
Why not?
> Thoughts?
Ideally someone would try and get rid of mmap_sem itself.. but that's a
tough nut.
> void rt_down_write(struct rw_semaphore *rwsem)
> {
> - rwsem_acquire(&rwsem->dep_map, 0, 0, _RET_IP_);
> - rt_mutex_lock(&rwsem->lock);
> + int i;
> + initialize_rwsem(rwsem);
> + for_each_possible_cpu(i) {
> + rwsem_acquire(&rwsem->lock[i].dep_map, 0, 0,
> _RET_IP_);
> + rt_mutex_lock(&rwsem->lock[i].lock);
> + }
> }
> EXPORT_SYMBOL(rt_down_write);
>
That'll make lockdep explode.. you'll want to make the whole set a
single lock and not treat it as nr_cpus locks.
next prev parent reply other threads:[~2012-05-15 15:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 14:03 [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks Steven Rostedt
2012-05-15 15:06 ` Peter Zijlstra [this message]
2012-05-15 15:42 ` Steven Rostedt
2012-05-15 17:25 ` Steven Rostedt
2012-05-15 17:31 ` Peter Zijlstra
2012-05-15 17:43 ` Steven Rostedt
2012-05-15 16:26 ` Steven Rostedt
2012-05-15 18:00 ` John Kacur
2012-05-15 18:14 ` Steven Rostedt
2012-05-17 15:18 ` Paul E. McKenney
2012-05-17 15:25 ` Paul E. McKenney
2012-05-17 15:32 ` Peter Zijlstra
2012-05-17 15:47 ` Paul E. McKenney
2012-05-17 16:17 ` Peter Zijlstra
2012-05-17 20:08 ` Paul E. McKenney
2012-05-17 20:20 ` Peter Zijlstra
2012-05-22 15:26 ` Thomas Gleixner
2012-05-22 15:50 ` Steven Rostedt
2012-05-22 16:40 ` Thomas Gleixner
2012-05-22 16:52 ` Steven Rostedt
2012-05-22 17:07 ` Thomas Gleixner
2012-05-22 17:50 ` Steven Rostedt
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=1337094383.27694.62.camel@twins \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=williams@redhat.com \
/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.