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 S934474AbcIVPL4 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 22 Sep 2016 11:11:56 -0400
Received: from mx2.suse.de ([195.135.220.15]:43548 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S933580AbcIVPLx (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 22 Sep 2016 11:11:53 -0400
Date: Thu, 22 Sep 2016 08:11:44 -0700
From: Davidlohr Bueso <dave@stgolabs.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
        Waiman Long <waiman.long@hpe.com>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Ingo Molnar <mingo@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
        linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
        Jason Low <jason.low2@hpe.com>, Scott J Norton <scott.norton@hpe.com>,
        Douglas Hatch <doug.hatch@hpe.com>
Subject: Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes
Message-ID: <20160922151144.GC13358@linux-80c1.suse>
References: <1474378963-15496-1-git-send-email-Waiman.Long@hpe.com>
 <1474378963-15496-4-git-send-email-Waiman.Long@hpe.com>
 <1474441172.27308.19.camel@gmail.com>
 <57E319BE.2050208@hpe.com>
 <20160922074932.GV5008@twins.programming.kicks-ass.net>
 <alpine.DEB.2.20.1609221236010.5599@nanos>
 <20160922144123.GB13358@linux-80c1.suse>
 <alpine.DEB.2.20.1609221641540.5599@nanos>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1609221641540.5599@nanos>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 22 Sep 2016, Thomas Gleixner wrote:

>On Thu, 22 Sep 2016, Davidlohr Bueso wrote:
>> On Thu, 22 Sep 2016, Thomas Gleixner wrote:
>> > Also what's the reason that we can't do probabilistic spinning for
>> > FUTEX_WAIT and have to add yet another specialized variant of futexes?
>>
>> Where would this leave the respective FUTEX_WAKE? A nop? Probably have to
>> differentiate the fact that the queue was empty, but there was a spinning,
>> instead of straightforward returning 0.
>
>Sorry, but I really can't parse this answer.
>
>Can you folks please communicate with proper and coherent explanations
>instead of throwing a few gnawed off bones in my direction?

I actually think that FUTEX_WAIT is the better/nicer approach. But my immediate
question above was how to handle the FUTEX_WAKE counter-part. If we want to
maintain current FIFO ordering for wakeups, now with WAIT spinners this will
create lock stealing scenarios (including if we even guard against starvation).
Or we could reduce the scope of spinners, due to the restrictions, similar to
the top-waiter only being able to spin for rtmutexes. This of course will hurt
the effectiveness of spinning in FUTEX_WAIT in the first place.

Another immediate thought was situations where we spinner(s) and the wait queue is
empty, the WAKE should also have to acknowledge that situation, as just returning 0
would indicate that there are actually no waiters on the futex.

Thanks,
Davidlohr