Messages in this thread | | | Date | Thu, 7 Feb 2013 16:35:59 -0800 | Subject | Re: [RFC PATCH 1/6] kernel: implement queue spinlock API | From | Michel Lespinasse <> |
| |
On Thu, Feb 7, 2013 at 2:34 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Tue, Jan 22, 2013 at 03:13:30PM -0800, Michel Lespinasse wrote: >> Introduce queue spinlocks, to be used in situations where it is desired >> to have good throughput even under the occasional high-contention situation. >> >> This initial implementation is based on the classic MCS spinlock, >> because I think this represents the nicest API we can hope for in a >> fast queue spinlock algorithm. The MCS spinlock has known limitations >> in that it performs very well under high contention, but is not as >> good as the ticket spinlock under low contention. I will address these >> limitations in a later patch, which will propose an alternative, >> higher performance implementation using (mostly) the same API.
While we're talking about MCS spinlocks, I should point out a potential issue I found about my 'faster queue spinlock' proposed MCS alternative. It is nice in that it avoids an atomic operation in the unlock path; however each unlocked lock must have a 'token' allocated and this token is accessed by the lock function. The issue with this is that if two threads don't actually block on each other, but they both access a lock that bounces between them, now the token will have to bounce between these threads as well, which is going to be more expansive than the atomic operation that was saved.
-- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies.
| |