From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753745AbcHWQ6e (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 12:58:34 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:44386 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752877AbcHWQ6c (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 12:58:32 -0400
Date: Tue, 23 Aug 2016 18:57:39 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Jason Low <jason.low2@hpe.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Waiman Long <waiman.long@hpe.com>,
        Ding Tianhong <dingtianhong@huawei.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Will Deacon <Will.Deacon@arm.com>, Ingo Molnar <mingo@redhat.com>,
        Imre Deak <imre.deak@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        "Paul E. McKenney" <paulmck@us.ibm.com>, jason.low2@hp.com
Subject: Re: [RFC][PATCH 0/3] locking/mutex: Rewrite basic mutex
Message-ID: <20160823165739.GQ10153@twins.programming.kicks-ass.net>
References: <20160823124617.015645861@infradead.org>
 <20160823161750.GD31186@linux-80c1.suse>
 <1471970103.2381.51.camel@j-VirtualBox>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1471970103.2381.51.camel@j-VirtualBox>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Aug 23, 2016 at 09:35:03AM -0700, Jason Low wrote:
> On Tue, 2016-08-23 at 09:17 -0700, Davidlohr Bueso wrote:
> > What's the motivation here? Is it just to unify counter and owner for
> > the starvation issue? If so, is this really the path we wanna take for
> > a small debug corner case?
> 
> And we thought our other patch was a bit invasive  :-)

So I've wanted to do something like this for a while now, and Linus
saying he wanted to always enable the spinning and basically reduce
special cases made me bite the bullet and just do it to see what it
would look like.

So it not only unifies counter and owner for the starvation case, it
does so to allow spinning and debug as well as lock handoff.
It collapses the whole count+owner+yield_to_owner into a single
variable.

It obviously is a tad invasive, but it does make things more similar to
rt-mutex and pi futex, both of which track the owner and pending in the
primary 'word'.

That said, I don't particularly like the new mutex_unlock() code, its
rather more heavy than I would like, although typically the word is
uncontended at unlock and we'd only need a single go at the
cmpxchg-loop.