Re: [rfc] "fair" rw spinlocks

Linus Torvalds
2009-11-30T22:49:33Z

On Mon, 30 Nov 2009, Thomas Gleixner wrote:
>
> I'm aware of that. The number of places where we read_lock
> tasklist_lock is 79 in 36 files right now. That's not a horrible task
> to go through them one by one and do a case by case conversion with a
> proper changelog. That would only leave the write_lock sites.

The write_lock sites should be fine, since just changing them to a
spinlock should be 100% semantically equivalent - except for the lack of
interrupt disable. And the lack of interrupt disable will result in a nice
big deadlock if some interrupt really does take the spinlock, which is
much easier to debug than a subtle race that would get the wrong read
value.

> We can then either do the rw_lock to spin_lock conversion or keep the
> rw_lock which has no readers anymore and behaves like a spinlock for a
> transition time so reverts of one of the read_lock -> rcu patches
> could be done to debug stuff.

So as per the above, I wouldn't worry about the write lockers. Might as
well change it to a spinlock, since that's what it will act as. It's not
as if there is any chance that the spinlock code is subtly buggy.

So the only reason to keep it as a rwlock would be if you decide to do the
read-locked cases one by one, and don't end up with all of them converted.
Which is a reasonable strategy too, of course. We don't _have_ to convert
them all - if the main problem is some starvation issue, it's sufficient
to convert just the main read-lock cases so that writers never get
starved.

But converting it all would be nice, because that whole

write_lock_irq(&tasklist_lock);

to

spin_lock(&tasklist_lock);

conversion would likely be a measurable performance win. Both because
spinlocks are fundamentally faster (no atomic on unlock), and because you
get rid of the irq disable/enable. But in order to get there, you'd have
to convert _all_ the read-lockers, so you'd miss the opportunity to only
convert the easy cases.

Linus