This is the mail archive of the
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: <email@example.com> <512FBE5E.firstname.lastname@example.org> <email@example.com>
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.