lkml.org 
[lkml]   [2013]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Preemptable Ticket Spinlock
    On 04/22/2013 04:08 PM, Peter Zijlstra wrote:
    > On Mon, 2013-04-22 at 15:56 -0400, Rik van Riel wrote:
    >> On 04/22/2013 03:49 PM, Peter Zijlstra wrote:
    >>> On Mon, 2013-04-22 at 08:52 -0400, Rik van Riel wrote:
    >>
    >>>> If the native spin_lock code has been called already at
    >>>> that time, the native code would still need to be modified
    >>>> to increment the ticket number by 2, so we end up with a
    >>>> compatible value in each spin lock's .tickets field, and
    >>>> prevent a deadlock after we switch over to the paravirt
    >>>> variant.
    >>>
    >>> I thought the stuff already made it upstream, but apparently not; the
    >>> lastest posting I'm aware of is here:
    >>>
    >>> https://lkml.org/lkml/2012/5/2/105
    >>>
    >>> That stuff changes the normal ticket increment as well..
    >>
    >> Jiannan,
    >>
    >> It looks like the patch above could make a good patch
    >> 1 (or 2) in your patch series :)
    >
    > I much prefer the entire series from Jeremy since it maintains the
    > ticket semantics and doesn't degrade the lock to unfair under
    > contention.
    >
    > Now I suppose there's a reason its not been merged yet and I suspect
    > its !paravirt hotpath impact which wasn't rightly justified or somesuch
    > so maybe someone can work on that or so.. dunno.

    IIRC one of the reasons was that the performance improvement wasn't
    as obvious. Rescheduling VCPUs takes a fair amount of time, quite
    probably more than the typical hold time of a spinlock.

    --
    All rights reversed


    \
     
     \ /
      Last update: 2013-04-22 23:01    [W:4.940 / U:0.408 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site