On Wed, Nov 10, 2021 at 05:53:57PM +0100, David Hildenbrand wrote: > On 10.11.21 17:49, Matthew Wilcox wrote: > > On Wed, Nov 10, 2021 at 04:37:14PM +0100, David Hildenbrand wrote: > >>> I'd suggest to make this new lock a special rwsem which allows either > >>> concurrent read access OR concurrent PTL access, but not both. This > >> > >> I looked into such a lock recently in similar context and something like > >> that does not exist yet (and fairness will be challenging). You either > >> have a single reader or multiple writer. I'd be interested if someone > >> knows of something like that. > > > > We've talked about having such a lock before for filesystems which want > > to permit either many direct-IO accesses or many buffered-IO accesses, but > > want to exclude a mixture of direct-IO and buffered-IO. The name we came > > up with for such a lock was the red-blue lock. Either Team Red has the > > lock, or Team Blue has the lock (or it's free). Indicate free with velue > > zero, Team Red with positive numbers and Team Blue with negative numbers. > > If we need to indicate an opposing team is waiting for the semaphore, > > we can use a high bit (1 << 30) to indicate no new team members can > > acquire the lock. Not sure whether anybody ever coded it up. > > Interesting, thanks for sharing! > > My excessive google search didn't reveal anything back then (~3 months > ago) -- only questions on popular coding websites asking essentially for > the same thing without any helpful replies. But maybe I used the wrong > keywords (e.g., "multiple reader, multiple writer", I certainly didn't > search for "red-blue lock", but I do like the name :) ). > > Fairness might still be the biggest issue, but I am certainly no locking > expert. Fairness could use the same basic logic as the write prefered to read in the rwsem. The atomic implementation would be with atomic_dec_unless_positive() and atomic_inc_unless_negative(), without fairness it looks straightfoward. Jason
