Re: [PATCH v8 15/19] locking/rwsem: Adaptive disabling of reader optimistic spinning

[Peter Zijlstra]

On Tue, Jun 04, 2019 at 02:04:34PM -0400, Waiman Long wrote:
> On 6/4/19 1:38 PM, Peter Zijlstra wrote:
> > On Tue, Jun 04, 2019 at 01:30:00PM -0400, Waiman Long wrote:
> >>> That's somewhat inconsistent wrt the type. I'll make it unsigned long,
> >>> as that is what makes most sense, given there's a pointer inside.
> >> Thank for spotting that, I will fix it.
> > I fixed a whole bunch of them; please find the modified patches here:
> >
> >   https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=locking/core
> 
> Thanks for reviewing the patches.
> 
> So how do you think about the overall state of this patchset? Do you
> think it is mature enough to go into 5.3?

So far so good :-)

> Or if you want more time to think about solving the RT thread issue, we
> can merge just patches 1-16 and play with the last threes for some more
> time. I am fine with that too as improving RT tasks is not my main
> focus. I like patch 16 as it led me to discover the rwsem reader wakeup
> bug as I hit the negative dentry count WARN_ON message in my testing.

My brain gave out around patch 14.. I'll try again tomorrow. But I'm
thinking we should be able to do as you suggest and get -16 merged.

> I worked on this owner merging patch mainly to alleviate the need to use
> cmpxchg for reader lock. cmpxchg_double() is certainly one possible
> solution though it won't work on older CPUs. We can have a config option
> to use cmpxchg_double as it may increase the size of other structures
> that embedded rwsem and impose additional alignment constraint.

cmpxchg8b was introduced with the Pentium (for PAE IIRC, it enabled
atomic 64bit PTEs, but Linux never used it for that) and every Intel/AMD
thereafter has had it. AFAIK there's no x86_64 chip without cmpxchg16b.