Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2] locking/rwsem: Take read lock immediate if queue empty
 with no writer
To:     Davidlohr Bueso <dave@stgolabs.net>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        linux-kernel@vger.kernel.org, Mark Ray <mark.ray@hpe.com>,
        Joe Mario <jmario@redhat.com>,
        Scott Norton <scott.norton@hpe.com>
References: <1531506653-5244-1-git-send-email-longman@redhat.com>
 <20180718161639.GT2494@hirez.programming.kicks-ass.net>
 <d9a125b2-3421-9c11-ff30-78812e42edc5@redhat.com>
 <20180723040423.hntq6dzzzf3sagfb@linux-r8p5>
From:   Waiman Long <longman@redhat.com>
Organization: Red Hat
Message-ID: <9722ffd0-9adb-9ad1-a05b-25869c0b2e60@redhat.com>
Date:   Mon, 23 Jul 2018 09:40:58 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <20180723040423.hntq6dzzzf3sagfb@linux-r8p5>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 07/23/2018 12:04 AM, Davidlohr Bueso wrote:
> On Wed, 18 Jul 2018, Waiman Long wrote:
>
>> The key here is that we don't want other incoming readers to observe
>> that there are waiters in the wait queue and hence have to go into the
>> slowpath until the single waiter in the queue is sure that it probably
>> will need to go to sleep if there is writer.
>>
>> With a constant stream of incoming readers, a major portion of them will
>> observe the a negative count and be serialized to enter the slowpath.
>> There are certainly other readers that do not observe the negative count
>> in the in between period after one reader clear the count in the unlock
>> path and a waiter set the count to negative again. Those readers can go
>> ahead and do the read in parallel. But it is the serialized readers that
>> cause the performance loss and the observation of spinlock contention in
>> the perf output.
>
> This makes sense and seems feasible in that the optimization is done with
> the wait_lock held.
>
>>
>> It is the constant stream of incoming readers that sustain the spinlock
>> queue and the repeated clearing and negative setting of the count.
>
> This would not affect optimistic spinners that haven't yet arrived at the
> waitqueue phase because the lock is anonymously owned, so they won't spin
> in the first place, right?

The reader fastpath would have incremented the active count before
entering the slowpath. The spinning writer, seeing a non-zero active
count, will not attempt to steal the lock until the reader decrement the
count and set the waiting bias in one atomic op. Nothing will happen
before that.

-Longman