Travis (travis.downs.delete@this.gmail.com) on August 21, 2018 3:18 pm wrote:
>
> Maybe this lets you build the "holy grain" read-write lock for ready heavy scenarios?

Yes.

However, I warn you: we used to have something very much like those read-write locks in the kernel (we still do, but we used to have them too), and they have some really really nasty behavior.

It works well for the "writers are so rare that you don't have to care about it" cases.

And those cases do exist, but if writers sometimes aren't quite as rare as you thought, you're completely f*cked. It's going to be nasty.

So in the kernel we call this a percpu_rw_semaphore. and we have a handful of users of it. Things where reads happen all the time, but writes are a "almost never" thing. It's *that* bad. It ends up just falling back on the regular rwlock when contention happens, in order to not be horribly unfair.

So we basically use these "perfect rwlock" things to just make the case of "almost all readers" be really light-weight, but then when that isn't the case, the code falls back on a normal fair rwlock to not be outrageously bad.

Because it turns out that sometimes "fairness" is actually more important than absolute performance, because unfair locks can have worst-case scenarios that are so bad that even if they are faster on average, they are completely unacceptable in reality.

And sometimes it takes a long time (and a really big machine) to hit one of those worst-case things, so you think it's a wonderful solution for the longest time.

But by all means - play around with it. Tricks like this is exactly what rseq could be used for. I just wanted to warn you about how percpu lock models haven't necessarily been great.

Linus