Travis (travis.downs.delete@this.gmail.com) on August 21, 2018 4:27 pm wrote:
>
> The unfairness that was problematic was a constant stream of readers
> starving out writers, or between various writers or what?

We've had that, yes (and in fact, we've had that even for the regular rwlocks).

It's really nice when it works, but it can get really outrageously bad when there is contention. And the unfairness can become visible in the cache coherency protocol itself, where a CPU that just owned a lock has a much easier time grabbing it again immediately, because it might still be exclusive in the caches.

There's no guarantee that the cache coherency is fair, after all.

So we've almost invariably had to build in fairness in the queuing itself. Our spinlocks, for example, are not just a "owner" lock. No, they are ticket locks, so that people that get blocked on a spinlock get a particular ordering, and you don't get in the situation that some CPU's have an easier time re-taking the lock than others.

And yes, that ended up slowing the spinlocks down and making them more complex, but not really noticeably so - and the unfairness case was really noticeable on some big machines. To the point where people had watchdogs fire because some CPU wouldn't make progress for tens of seconds at a time, just because other CPU's could re-take the lock so quickly.

So I used to detest fairness. It makes locking harder and slower. But almost every time, we've found that if something can get contended, fairness isn't just a good idea, it's pretty much required.

> A reasonable strategy would seem to be to make such locks favor writers as far as fairness goes: once
> a writer expresses interest, no new readers enter the critical section.

That ends up being potentially even worse, because quite often the reader is the critical case, and the writer has to wait for other readers to finish anyway, so a writer-favoring lock can be really bad and then cause hickups for the readers, in case there is some way an untrusted user can schedule writers.

So what we do (and I might mis-remember) is

- if it sees the "no writer" flag, it just increments the percpu reader count, and is done

which basically makes the "default" reader case optimal. This is all done non-preemptibly because of that percpu sequence, of course.

But whenever a writer shows up, the percpu fast case simply goes away, and we fall back to a fair rwlock. Obviously with some logic on the part of the writer to wait for the readers that came in before it marked itself (by adding up those percpu counts).

So the percpu rwlock basically ends up just being a n almost perfectly normal rwlock when writers are around, but has a special fast-case for when there are no writers and it can use pure percpu accounting of readers. And there's some percpu and RCU logic for some of the serialization issues between these two states.

I may have oversimplified and misstated it a bit, but it's close to something like that.

Linus