[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 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 <>
>>> Changelog:
>>> Reordering in header files and adding declarations to enable
>>> spinlock header to use jump label technique.
>>> Signed-off-by: Raghavendra K T <>
>>> ---
>>> I was re-basing Jermey patches (, 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.


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