On Tue 17-01-23 10:28:40, Suren Baghdasaryan wrote: [...] > > Then yes, that's a starvable lock. Preventing starvation on the mmap > > sem was the original motivation for making rwsems non-starvable, so > > changing that behaviour now seems like a bad idea. For efficiency, I'd > > suggest that a waiting writer set the top bit of the counter. That way, > > all new readers will back off without needing to check a second variable > > and old readers will know that they *may* need to do the wakeup when > > atomic_sub_return_release() is negative. > > > > (rwsem.c has a more complex bitfield, but I don't think we need to go > > that far; the important point is that the waiting writer indicates its > > presence in the count field so that readers can modify their behaviour) > > Got it. Ok, I think we can figure something out to check if there are > waiting write-lockers and prevent new readers from taking the lock. Reinventing locking primitives is a ticket to weird bugs. I would stick with the rwsem and deal with performance fallouts after it is clear that the core idea is generally acceptable and based on actual real life numbers. This whole thing is quite big enough that we do not have to go through "is this new synchronization primitive correct and behaving reasonably" exercise. -- Michal Hocko SUSE Labs
