Messages in this thread |  | | Subject | Re: Jump Label initialization | | From | Steven Rostedt <> | | Date | Thu, 29 Sep 2011 08:40:26 -0400 |
| |
On Thu, 2011-09-29 at 14:04 +0200, Jan Glauber wrote: > On Wed, 2011-09-28 at 19:14 -0700, Jeremy Fitzhardinge wrote: > > Hi all, > > > > I'm trying to use the jump label machinery as part of the pv ticketlock > > work I'm doing on x86. > > > > The problem I'm having at the moment is that I do my spinlock setup in > > smp_prepare_boot_cpu(), which happens before jump_label_init() gets > > called, and so the latter goes and nops out all my enabled jump label key. > > > > I'm experimenting at the moment with a patch to allow > > jump_label_enable() to be called fairly early, and have that be > > respected by jump_label_init(). I'm doing this by replacing > > arch_jump_label_poke_text_early() with > > arch_jump_label_transform_early(), which shares most of its code with > > its non-early variant, except that it expects to run in a pre-SMP > > environment. > > > > Does this seem plausible? (I haven't tested it yet.) > > > > The x86, mips and sparc patches are fairly simple; I forgot to look at > > powerpc, and I didn't fully investigate s390. > > s390 does not have the early() variant since it didn't need it. On > pre-SMP we probably don't need stop_machine() so creating > arch_jump_label_transform_early() by leaving out stop_machine() > and patching the code directly should be fine.
Also note that stop_machine() may only be needed by a few archs (maybe only x86).
x86 has a nasty condition if you change code that is being loaded in another CPUs pipeline, it could cause a GPF. I've been playing with this on PPC and this does not have that same bug. In fact Benjamin told me that PPC is fine with modifying instructions on a running system.
I plan on removing the stop_machine() from ftrace for those boxes. I already have patches made, just need to spiffy them up a bit.
-- Steve
|  |