Date: Thu, 20 Apr 2017 19:53:50 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: mingo@kernel.org, akpm@linux-foundation.org, jack@suse.cz,
        kirill.shutemov@linux.intel.com, ldufour@linux.vnet.ibm.com,
        mhocko@suse.com, mgorman@techsingularity.net,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 -tip 0/6] locking: Introduce range reader/writer lock
Message-ID: <20170420175350.44mvhizyulyzb6oc@hirez.programming.kicks-ass.net>
References: <20170406084620.22700-1-dave@stgolabs.net>
 <20170419123735.GB5730@worktop>
 <20170420171326.GD20746@linux-80c1.suse>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170420171326.GD20746@linux-80c1.suse>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 625
Lines: 13

On Thu, Apr 20, 2017 at 10:13:26AM -0700, Davidlohr Bueso wrote:

> I have thought of some heuristics for avoiding sleeping under certain
> constraints, which could mitigate the spinning step we loose, but I fear it
> will never be exactly as fast as rwsems -- just consider
> we always take the tree->lock.

But tree->lock is a spinlock, so while this gets us out of rwsem-xadd
territory for the fast paths, the whole lock-stealing and optimistic
spinning stuff is on a different scale.

Those are about avoiding actually going to sleep and having to be woken
up (and waiting to become running) again, which is a long time.