[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0911300706420.2872@localhost.localdomain>
Date: Mon, 30 Nov 2009 07:22:13 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nick Piggin <npiggin@...e.de>
cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Paul McKenney <paulmck@...ibm.com>
Subject: Re: [rfc] "fair" rw spinlocks
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists