From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
linux-kernel@vger.kernel.org, ego@in.ibm.com
Subject: Re: New filesystem for Linux
Date: Fri, 3 Nov 2006 12:02:34 -0800 [thread overview]
Message-ID: <20061103200234.GA2610@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0611021458240.25218@g5.osdl.org>
On Thu, Nov 02, 2006 at 03:15:33PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 2 Nov 2006, Mikulas Patocka wrote:
> >
> > * There is a rw semaphore that is locked for read for nearly all operations
> > and locked for write only rarely. However locking for read causes cache line
> > pingpong on SMP systems. Do you have an idea how to make it better?
[ . . . ]
> (Seqlocks could be changed to drop the first requirement, although it
> could cause some serious starvation issues, so I'm not sure it's a good
> idea. For RCU the atomic nature is pretty much designed-in.)
I can't help putting in a plug for SRCU, which is in the 2.6.19-rc series,
and which allows readers to sleep. (http://lwn.net/Articles/202847/)
SRCU allows readers and writers to run concurrently (as do all forms of
RCU). If this is a problem, it might be worth looking into Gautham
Shenoy's reader-writer lock built on top of RCU. (A version for hotplug
may be found at http://lkml.org/lkml/2006/10/26/73.) This approach
keeps the reader-writer-lock semantics, but gets rid of cache thrashing.
That said, writers have to wait for a grace period.
And as Linus pointed out, if you have disk I/O involved, you probably
won't notice normal reader-writer-lock overhead.
Thanx, Paul
next prev parent reply other threads:[~2006-11-03 20:01 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 21:52 New filesystem for Linux Mikulas Patocka
2006-11-02 22:32 ` Gabriel C
2006-11-03 1:22 ` Mikulas Patocka
2006-11-03 1:41 ` Andrew Morton
2006-11-03 17:14 ` Oleg Verych
2006-11-03 17:09 ` Mikulas Patocka
2006-11-03 17:36 ` Oleg Verych
2006-11-03 18:14 ` Mikulas Patocka
2006-11-03 19:08 ` Adrian Bunk
2006-11-03 19:32 ` Oleg Verych
2006-11-03 19:00 ` Alan Cox
2006-11-03 19:14 ` Andi Kleen
2006-11-03 2:09 ` Gabriel C
2006-11-03 8:26 ` Jan Engelhardt
2006-11-03 11:52 ` Mikulas Patocka
2006-11-03 11:59 ` Mikulas Patocka
2006-11-03 12:50 ` Jan Engelhardt
2006-11-03 18:48 ` Mikulas Patocka
2006-11-03 21:51 ` Jan Engelhardt
2006-11-03 11:47 ` Mikulas Patocka
2006-11-02 22:53 ` Eric Dumazet
2006-11-03 1:28 ` Mikulas Patocka
2006-11-03 1:43 ` Andrew Morton
2006-11-04 18:40 ` Mikulas Patocka
2006-11-04 19:07 ` Eric Dumazet
2006-11-04 19:39 ` Tomasz Torcz
2006-11-05 1:58 ` Alan Cox
2006-11-05 2:09 ` Patrick McFarland
2006-11-05 13:03 ` Maurizio Lombardi
2006-11-05 20:16 ` H. Peter Anvin
2006-11-02 22:54 ` Grzegorz Kulewski
2006-11-02 23:10 ` Eric Dumazet
2006-11-02 23:19 ` Mikulas Patocka
2006-11-02 23:29 ` Grzegorz Kulewski
2006-11-03 1:34 ` Mikulas Patocka
2006-11-03 20:30 ` Christoph Lameter
2006-11-04 18:46 ` Mikulas Patocka
2006-11-05 12:02 ` Theodore Tso
2006-11-03 22:00 ` Oleg Verych
2006-11-03 22:42 ` Mikulas Patocka
2006-11-03 0:57 ` Nigel Cunningham
2006-11-03 13:05 ` Ric Wheeler
2006-11-06 2:42 ` Phillip Susi
2006-11-04 19:59 ` Albert Cahalan
2006-11-04 21:01 ` Jan-Benedict Glaw
2006-11-05 16:37 ` Albert Cahalan
2006-11-04 23:38 ` Mikulas Patocka
2006-11-04 23:46 ` Kyle Moffett
2006-11-05 20:26 ` H. Peter Anvin
2006-11-05 21:27 ` Rene Herman
2006-11-05 21:51 ` H. Peter Anvin
2006-11-06 0:36 ` Rene Herman
2006-11-05 21:49 ` Pavel Machek
2006-11-05 1:57 ` Alan Cox
2006-11-05 11:14 ` James Courtier-Dutton
2006-11-05 11:27 ` Brad Campbell
2006-11-05 12:37 ` Alan Cox
2006-11-06 2:48 ` Phillip Susi
2006-11-05 16:22 ` Albert Cahalan
2006-11-05 17:18 ` Mikulas Patocka
2006-11-05 18:14 ` Alan Cox
2006-11-05 18:18 ` Mikulas Patocka
2006-11-05 19:14 ` Alan Cox
2006-11-02 23:15 ` Linus Torvalds
2006-11-03 20:02 ` Paul E. McKenney [this message]
2006-11-02 23:41 ` Andi Kleen
2006-11-03 1:45 ` Mikulas Patocka
2006-11-03 13:47 ` Nikita Danilov
2006-11-03 14:39 ` Mikulas Patocka
2006-11-02 23:59 ` Jörn Engel
2006-11-03 1:19 ` Mikulas Patocka
2006-11-03 10:19 ` Jörn Engel
2006-11-03 11:56 ` Mikulas Patocka
2006-11-03 12:21 ` Jörn Engel
2006-11-03 13:31 ` Mikulas Patocka
2006-11-03 13:48 ` Jörn Engel
2006-11-03 14:19 ` Mikulas Patocka
2006-11-03 14:53 ` Jörn Engel
2006-11-03 19:01 ` Mikulas Patocka
2006-11-04 10:46 ` Jörn Engel
2006-11-04 18:50 ` Mikulas Patocka
2006-11-06 21:19 ` Jörn Engel
2006-11-03 19:51 ` Adrian Bunk
2006-11-03 19:00 ` dean gaudet
2006-11-04 10:53 ` Jörn Engel
2006-11-04 11:13 ` dean gaudet
2006-11-04 20:07 ` Jörn Engel
2006-11-04 18:52 ` Mikulas Patocka
2006-11-04 18:56 ` Grzegorz Kulewski
2006-11-04 19:18 ` Mikulas Patocka
2006-11-04 17:37 ` Gautham R Shenoy
2006-11-04 18:27 ` Eric Dumazet
2006-11-05 22:33 ` Paul E. McKenney
2006-11-05 0:52 ` Linus Torvalds
2006-11-05 4:14 ` Mikulas Patocka
2006-11-05 8:34 ` Willy Tarreau
2006-11-05 11:31 ` Jan Engelhardt
2006-11-05 14:48 ` Bruno Cesar Ribas
-- strict thread matches above, loose matches on Subject: below --
2006-11-06 17:40 Al Boldi
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=20061103200234.GA2610@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=torvalds@osdl.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.