* Jason Baron (jbaron@redhat.com) wrote:
quoted text
> On Tue, Oct 19, 2010 at 07:05:15PM -0400, Steven Rostedt wrote:
> > On Tue, 2010-10-19 at 15:49 -0700, H. Peter Anvin wrote:
> > > On 10/19/2010 03:41 PM, Mathieu Desnoyers wrote:
> > > >>
> > > >> OK, first of all, there are some serious WTFs here:
> > > >>
> > > >> # define JUMP_LABEL_INITIAL_NOP ".byte 0xe9 \n\t .long 0\n\t"
> > > >>
> > > >> A jump instruction is one of the worst possible NOPs.  Why are we doing
> > > >> this?
> > > > 
> > > > This code is dynamically patched at boot time (and module load time) with a
> > > > better nop, just like the function tracer does.
> > > > 
> > > 
> > > That's just ridiculous... start out with something sane and you at least
> > > have the chance of not having to patch it.
> > 
> > Yep we can fix this. Jason?
> > 
> 
> sure. The idea of the 'jmp 0' was simply to be an lcd for x86, if
> there's a better lcd for x86, I'll update it. But note, that since the
> 'jmp 0' is patched to a better nop at boot, we wouldn't see much gain.
> And in the boot path we are using 'text_poke_early()', so avoiding that
> isn't going to improve things much.
> 
> I've got a few fixup patches in the queue that I'm going to post first,
> and then I'll take a look at this change.

One thing to consider here is that some nops are not compatible across all
architectures. And it would be safer to use an atomic nops (a single
instruction) too. e.g.  GENERIC_NOP5 in arch/x86/include/asm/nops.h is really 2
instructions, which can cause problems if a concurrent thread is preempted
between the two instructions while we patch.

arch_init_ideal_nop5() is actually doing the task of finding the best nop, and
it falls-back on a 5-byte nop (just like you do).

HPA, do you have any recommendation for a 5-byte single-instruction nop that is
efficient enough and will work on all x86 (Intel, AMD and other variants) ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/