lkml.org 
[lkml]   [2012]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/1] linux headers: header file(s) changes to enable spinlock use jumplabel
    On 02/20/2012 10:46 AM, Jeremy Fitzhardinge wrote:
    [...]
    >>>> So we get following error when we try to include jump_label.h from
    >>>> arch/x86/include/asm/spinlock.h because of cyclic dependency
    >>>> <spinlock.h> -> <jumplabe.h> -> <workque.h> -> ...<seqlock.h> -> <spinlock.h>
    >>> What about splitting the jump_label_key_deferred stuff into a separate
    >>> jump_label_deferred.h, and just include that where it's needed?
    >>>
    >> Andrew Jones did exactly that (CCed).

    Sorry, did not get it. Tried to search the patch. Is it similar
    work or same work?. Could you please point. shall try both the way
    (current way and jump_label_deferred way). So whichever makes maintainer
    happy, let that go :)

    But does pvlock have to use jump
    >> label? I looked at the code and it is used like paravirt patching. Meaning
    >> it is patched only once on a boot up when XEN is detected. May be use
    >> paravirt patching instead of jump label? What if jump label will want
    >> to use spinlock for some reason in the future (it uses mutex currently)?
    >
    > The point of the pv ticketlocks is to avoid any pvop calls on the
    > lock/unlock fastpath, relegating them to only the slow path.
    > Unfortunately, the pv unlock case can't be identical with the non-pv
    > unlock, and jump_labels are lighter weight and more efficient than pvops.
    >
    > It doesn't matter if jump_labels start using spinlocks; all we need the
    > jump_label machinery to do is patch the jump sites in the code so that
    > one of two execution paths can be selected. Since all the ticketlock
    > jump_label patching happens before SMP is enabled, there's no problem
    > with changing a lock while a cpu is executing the code.
    >

    I also felt agreeing with Jeremy. seemed to me that latter is more
    performance friendly. no?.

    (Hmm. Thinking.. By the way is it not that Jeremy's earlier version
    had implementation similar to what Gleb asked ?)



    \
     
     \ /
      Last update: 2012-02-20 07:17    [W:2.593 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site