Messages in this thread | | | Date | Mon, 30 Nov 2009 07:22:13 -0800 (PST) | From | Linus Torvalds <> | 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
| |