On Wed, Apr 24, 2019 at 10:02 AM Peter Zijlstra <pet...@infradead.org> wrote: > > > For an uncontended rwsem, this offers no real benefit. Adding > > preempt_disable() is more complicated than I originally thought. > > I'm not sure I get your objection?
I'm not sure it's an objection, but I do think that it's sad if we have to do the preempt_enable/disable around the fastpath. Is the *only* reason for the preempt-disable to avoid the (very unlikely) case of unbounded preemption in between the "increment reader counts" and "decrement it again because we noticed it turned negative"? If that's the only reason, then I think we should just accept the race. You still have a "slop" of 15 bits (so 16k processes) hitting the same mutex, and they'd all have to be preempted in that same "small handful instructions" window. Even if the likelihood of *one* process hitting that race is 90% (and no, it really isn't), then the likelihood of having 16k processes hitting that race is 0.9**16384. We call numbers like that "we'll hit it some time long after the heat death of the universe" numbers. Linus