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 S1753705AbcHWQgA (ORCPT <rfc822;w@1wt.eu>);
        Tue, 23 Aug 2016 12:36:00 -0400
Received: from g1t6214.austin.hp.com ([15.73.96.122]:36458 "EHLO
        g1t6214.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752962AbcHWQf6 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 23 Aug 2016 12:35:58 -0400
Message-ID: <1471970103.2381.51.camel@j-VirtualBox>
Subject: Re: [RFC][PATCH 0/3] locking/mutex: Rewrite basic mutex
From: Jason Low <jason.low2@hpe.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: jason.low2@hpe.com, Peter Zijlstra <peterz@infradead.org>,
        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
Date: Tue, 23 Aug 2016 09:35:03 -0700
In-Reply-To: <20160823161750.GD31186@linux-80c1.suse>
References: <20160823124617.015645861@infradead.org>
         <20160823161750.GD31186@linux-80c1.suse>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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  :-)

> I have not looked at the patches yet, but are there any performance minutia
> to be aware of?

This would remove all of the mutex architecture specific optimizations
in the (common) fastpath, so that is one thing that could reduce
performance. I'll run some benchmarks to see what some of the
performance impacts of these patches would be.