[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1604031158110.3978@nanos>
Date: Sun, 3 Apr 2016 11:59:07 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: LKML <linux-kernel@...r.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Darren Hart <darren@...art.com>,
Ingo Molnar <mingo@...nel.org>,
Michael Kerrisk <mtk.manpages@...glemail.com>,
Davidlohr Bueso <dave@...olabs.net>, Chris Mason <clm@...com>,
Carlos O'Donell <carlos@...hat.com>,
Torvald Riegel <triegel@...hat.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [RFC patch 4/7] futex: Add support for attached futexes
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
Powered by blists - more mailing lists