From: Linus Torvalds <torvalds@linux-foundation.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Paul McKenney <paulmck@us.ibm.com>
Subject: Re: [rfc] "fair" rw spinlocks
Date: Mon, 30 Nov 2009 07:22:13 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0911300706420.2872@localhost.localdomain> (raw)
In-Reply-To: <20091130075557.GI17484@wotan.suse.de>
On Mon, 30 Nov 2009, Nick Piggin wrote:
>
> We do have quite a large number of rwlocks really.
Dynamically they tend to be unimportant, except for the tasklist_lock.
Many of them are in drivers and/or finegrained, or get called only by
fairly unusual things (registering filesystems etc).
> If they are so important as to be rwlocks,
Stop making total red-herring arguments.
It's not about "so important as to be rwlocks". Quite the reverse. I'm
saying that most rwlocks are totally _unimportant_. Being a rwlock does
_not_ make anything more important or less important in itself, so your
argument is bogus. You have to base importantness on other issues than
whether they are rwlocks or not.
As far as I can tell there is _one_ single important rwlock, and that's
tasklist_lock. Everything else could probably trivially and individually
be turned into a spinlock if fairness matters for them. But tasklist_lock
fundamentally depends on the semantics of rwlocks.
And that one rwlock requires unfair behavior, and is not going to be happy
with some more complicated thing (because it is also called from some
pretty critical pathways).
So my argument is purely:
- there is absolutely NOBODY who cares about "fair" rwlocks, because no
other user will ever hit its lock enough for it to matter. And if they
really do, most of them tend to be fairly simple and localized and
might be turned into spinlocks.
- the _one_ major exception to this - somebody who does hit the lock
enough for fairness to matter - is not likely amenable to any kind of
trivial fairness.
Now, I'd love to come up with some solution to tasklist_lock, but I just
don't see it. At least nothing easy that doesn't have tons of downsides
(like turning it into a spinlock, using the irq-safe versions, and having
irq's potentially disabled for much longer than I think is good).
Linus
next prev parent reply other threads:[~2009-11-30 15:22 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-23 14:54 [rfc] "fair" rw spinlocks Nick Piggin
2009-11-24 20:19 ` David Miller
2009-11-25 6:52 ` Nick Piggin
2009-11-25 8:49 ` Andi Kleen
2009-11-25 8:56 ` Nick Piggin
2009-11-24 20:47 ` Andi Kleen
2009-11-25 6:54 ` Nick Piggin
2009-11-25 8:48 ` Andi Kleen
2009-11-25 13:09 ` Arnd Bergmann
2009-11-28 2:07 ` Paul E. McKenney
2009-11-28 11:15 ` Andi Kleen
2009-11-28 15:20 ` Paul E. McKenney
2009-11-28 17:30 ` Linus Torvalds
2009-11-29 18:51 ` Paul E. McKenney
2009-11-30 7:57 ` Nick Piggin
2009-11-30 7:55 ` Nick Piggin
2009-11-30 15:22 ` Linus Torvalds [this message]
2009-11-30 15:40 ` Nick Piggin
2009-11-30 16:07 ` Linus Torvalds
2009-11-30 16:17 ` Nick Piggin
2009-11-30 16:39 ` Paul E. McKenney
2009-11-30 17:05 ` Linus Torvalds
2009-11-30 17:13 ` Nick Piggin
2009-11-30 17:18 ` Linus Torvalds
2009-12-01 17:03 ` Arnd Bergmann
2009-12-01 17:15 ` Linus Torvalds
2009-11-30 18:29 ` Paul E. McKenney
2009-11-30 16:20 ` Paul E. McKenney
2009-11-30 10:00 ` Christoph Hellwig
2009-11-30 15:52 ` Linus Torvalds
2009-11-30 17:46 ` Ingo Molnar
2009-11-30 21:12 ` Thomas Gleixner
2009-11-30 21:27 ` Peter Zijlstra
2009-11-30 22:02 ` Thomas Gleixner
2009-11-30 22:11 ` Linus Torvalds
2009-11-30 22:37 ` Thomas Gleixner
2009-11-30 22:49 ` Linus Torvalds
2009-12-01 17:37 ` [PATCH] audit: Call tty_audit_push_task() outside preempt disabled region Thomas Gleixner
2009-12-01 18:22 ` Oleg Nesterov
2009-12-01 19:53 ` Thomas Gleixner
2009-12-06 3:12 ` [rfc] "fair" rw spinlocks Eric W. Biederman
2009-12-07 18:18 ` Paul E. McKenney
2009-12-07 22:24 ` Eric W. Biederman
2009-12-07 22:35 ` Andi Kleen
2009-12-07 23:19 ` Eric W. Biederman
2009-12-08 1:39 ` Paul E. McKenney
2009-12-08 2:11 ` Eric W. Biederman
2009-12-08 2:37 ` Paul E. McKenney
2009-12-07 18:32 ` Oleg Nesterov
2009-12-07 20:38 ` Peter Zijlstra
2009-12-09 15:55 ` Oleg Nesterov
2009-12-07 22:10 ` Eric W. Biederman
2009-12-09 15:37 ` Oleg Nesterov
2009-12-10 3:36 ` Eric W. Biederman
2009-12-10 6:22 ` Paul E. McKenney
2009-12-10 10:31 ` Eric W. Biederman
2009-12-10 16:41 ` Paul E. McKenney
2009-12-01 19:01 ` Mathieu Desnoyers
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=alpine.LFD.2.00.0911300706420.2872@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=paulmck@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox