This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] improving spinning in adaptive mutexes
- From: Chris Metcalf <cmetcalf at tilera dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, "Kleen, Andi"<andi dot kleen at intel dot com>
- Date: Fri, 1 Mar 2013 10:15:13 -0500
- Subject: Re: [RFC] improving spinning in adaptive mutexes
- References: <1362067023.581.14702.camel@triegel.csb> <512FBE5E.6050205@tilera.com> <1362149872.3117.587.camel@triegel.csb>
On 3/1/2013 9:57 AM, Torvald Riegel wrote:
> Do you have any suggestions for what would be appropriate back-off on Tilera archs, and why? I don't have access to the hardware, so I couldn't make a guess based on experiments.
Our code typically uses a pattern of starting with ~20 cycles backoff, then does bounded exponential backoff up to about ~2000 cycles. The high backoff is helpful on a 64+ core chip when all the cores end up trying to acquire a lock at once. If cores are sending too many requests at once, what happens is that (since we have a 2D mesh network for communications) cores nearer to the home cache of the lock end up getting preferentially serviced and the farther away cores can take quite a while to be serviced.
See arch/tile/lib/spinlock_common.h in the Linux sources for some sample code.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com