Re: [PATCH 1/1] linux headers: header file(s) changes to enable spinlockuse jumplabel

[Raghavendra K T]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/