Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753137AbcDCKAp (ORCPT <rfc822;w@1wt.eu>);
	Sun, 3 Apr 2016 06:00:45 -0400
Received: from www.linutronix.de ([62.245.132.108]:58644 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752426AbcDCKAo (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 3 Apr 2016 06:00:44 -0400
Date: Sun, 3 Apr 2016 11:59:07 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
cc: LKML <linux-kernel@vger.kernel.org>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Darren Hart <darren@dvhart.com>, Ingo Molnar <mingo@kernel.org>,
        Michael Kerrisk <mtk.manpages@googlemail.com>,
        Davidlohr Bueso <dave@stgolabs.net>, Chris Mason <clm@fb.com>,
        "Carlos O'Donell" <carlos@redhat.com>,
        Torvald Riegel <triegel@redhat.com>,
        Eric Dumazet <edumazet@google.com>
Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes
In-Reply-To: <20160402162903.GR3448@twins.programming.kicks-ass.net>
Message-ID: <alpine.DEB.2.11.1604031158110.3978@nanos>
References: <20160402095108.894519835@linutronix.de> <20160402110035.753145539@linutronix.de> <20160402162903.GR3448@twins.programming.kicks-ass.net>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 911
Lines: 34

On Sat, 2 Apr 2016, Peter Zijlstra wrote:
> On Sat, Apr 02, 2016 at 11:09:18AM -0000, Thomas Gleixner wrote:
> > +	/*
> > +	 * Lock the global hash bucket. Decrement global state refcount. If 0
> > +	 * remove it from the global hash and free it.
> > +	 */
> > +	spin_lock(&hb->lock);
> > +	if (--fs->refcount == 0)
> > +		hb_remove_q(q, hb);
> > +	else
> > +		fs = NULL;
> > +	spin_unlock(&hb->lock);
> 
> So you could play funny games like:
> 
> 	if (atomic_add_unless(&fs->recount, -1, 1))
> 		return;
> 
> 	spin_lock(&hb->lock);
> 	if (atomic_dec_return(&fs->refcount) == 0)
> 		hb_remove_q(q, hb);
> 	else
> 		fs = NULL;
> 	spin_unlock(&hb->lock);
> 
> To avoid taking that lock entirely in the 'fast' path, but I'm not sure
> how performance critical this path is.

Attach/detach is not really critical. The futex ops are critical and they do
not touch the global hash bucket lock at all.

Thanks,

	tglx