[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1387567810.2704.19.camel@buesod1.americas.hpqcorp.net>
Date: Fri, 20 Dec 2013 11:30:10 -0800
From: Davidlohr Bueso <davidlohr@...com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Darren Hart <dvhart@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Mike Galbraith <efault@....de>, Jeff Mahoney <jeffm@...e.com>,
Jason Low <jason.low2@...com>,
Waiman Long <Waiman.Long@...com>, Tom Vaden <tom.vaden@...com>,
"Norton, Scott J" <scott.norton@...com>,
"Chandramouleeswaran, Aswin" <aswin@...com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v3 4/4] futex: Avoid taking hb lock if nothing to wakeup
On Thu, 2013-12-19 at 15:14 -0800, Linus Torvalds wrote:
>
> So I still think this can be done without that new counter field, or
> any new atomics.
>
> hb_waiters_pending() could be something like
>
> spin_contended(hb->lock) || !list_empty(&hb->chain)
>
> which considering where you increment the new count should be
> equivalent to your "!!hb->waiters". The smp_mb_after_atomic_inc()" on
> the spinlock side would become smp_mb_after_spin_lock() instead.
So we'd need the barrier right after the ticket increment (ie: the xadd
TICKET_LOCK_INC in x86), and cannot rely on the barrier after the lock
is taken as we could miss waiters that are just spinning trying to take
it. Is this implicitly guaranteed across all archs?
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists