[lkml]   [2012]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/1] linux headers: header file(s) changes to enable spinlock use jumplabel
    On Mon, Feb 20, 2012 at 11:44:25AM +0530, Raghavendra K T wrote:
    > 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 :)
    It was not CCed to any ML. I CCed Andrew so he can chime in.

    > 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?.

    I thought not about pvop, but about alternative(). jump_labels is used
    by spinlock to patch out jump into nops It can be done via alternative()
    too I think.

    > (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 10:37    [W:0.024 / U:45.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site