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

[Jeremy Fitzhardinge]

On 02/19/2012 01:24 AM, Gleb Natapov wrote:
> On Sat, Feb 18, 2012 at 03:21:12PM -0800, Jeremy Fitzhardinge wrote:
>> On 02/17/2012 12:25 AM, Raghavendra K T wrote:
>>> From:  Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
>>>
>>> Changelog:
>>>   Reordering in header files and adding declarations to enable
>>>  spinlock header to use jump label technique.
>>>     
>>> Signed-off-by: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
>>> ---
>>>  I was re-basing Jermey patches (https://lkml.org/lkml/2011/10/12/496), while working
>>> on paravirtualized ticket spinlock (3.3.-rc3).
>>>
>>> Currently <jump_label.h> includes <workqueue.h> (commit: b202952075f62603bea9bfb6ebc6b0420db11949)
>>>
>>>  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). 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.

    J
--
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/