[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F41D72E.7000605@goop.org>
Date: Sun, 19 Feb 2012 21:16:30 -0800
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Gleb Natapov <gleb@...hat.com>
CC: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
Tejun Heo <tj@...nel.org>, John Stultz <johnstul@...ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
David Howells <dhowells@...hat.com>,
Andrew Jones <drjones@...hat.com>
Subject: Re: [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 <raghavendra.kt@...ux.vnet.ibm.com>
>>>
>>> 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@...ux.vnet.ibm.com>
>>> ---
>>> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists