lkml.org 
[lkml]   [2012]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 3/3 -v2] x86,smp: auto tune spinlock backoff delay factor
    On 12/21/2012 07:18 PM, Eric Dumazet wrote:
    > On Fri, 2012-12-21 at 18:56 -0500, Rik van Riel wrote:
    >> Argh, the first one had a typo in it that did not influence
    >> performance with fewer threads running, but that made things
    >> worse with more than a dozen threads...
    >
    >> +
    >> + /*
    >> + * The lock is still busy, the delay was not long enough.
    >> + * Going through here 2.7 times will, on average, cancel
    >> + * out the decrement above. Using a non-integer number
    >> + * gets rid of performance artifacts and reduces oversleeping.
    >> + */
    >> + if (delay < MAX_SPINLOCK_DELAY &&
    >> + ((inc.head & 3) == 0 || (inc.head & 7) == 1))
    >> + delay++;
    >
    > ((inc.head & 3) == 0 || (inc.head & 7) == 1)) seems a strange condition
    > to me...

    It is. It turned out that doing the increment
    every 4 times (just the first check) resulted
    in odd performance artifacts when running with
    4, 8, 12 or 16 CPUs.

    Moving to the above got rid of the performance
    artifact.

    It also results in aiming for a sleep period
    that is not an exact multiple of the lock
    acquiring period, which results in less
    "oversleeping", and measurably better
    performance.



    \
     
     \ /
      Last update: 2012-12-22 04:21    [W:4.370 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site