Linus Torvalds wrote:
quoted text
> On Fri, 5 Sep 2008, Jan Beulich wrote:
>   
>> I disagree here: If I configure a 686+ kernel, I expect these NOPs to be
>> that way (and to work). If you want to run on something that's not
>> compliant, you just shouldn't configure your kernel that way.
>>     
>
> Well, if you actually do a
>
> 	git grep 'ASM_NOP[0-9]'
>
> you'll find that just the _definitions_ of those things are the bulk of it 
> BY FAR, and that there doesn't seem to be a single user that cares even 
> remotely about performance.
>   

Well, the paravirt_ops patching uses multibyte nops to pad out the
unused space in a patch site, and they're generally on hot paths
(otherwise we wouldn't bother with patching).  But even then I don't
think the particular nop chosen matters all that much, and even if it
did using the dumb redundant prefix long nops seems to be as good as or
better than the p6 nops.  The "call mcount" patching ftrace wants to do
would also be pretty common.

quoted text
> So I actually think that the whole thing is a waste of time. We should 
> probably 
>
>  - pick a single set of NOP's per 32-bit/64-bit (since the good nops in 
>    32-bit aren't 64-bit instructions at all, so we do want different nops 
>    depending on _that_)
>
>    The whole static choice by microarchitecture is pure garbage.
>
>  - Probably also just declare that those default nops are single 
>    instructions, just so that we never even have to think about it from a 
>    dynamic replacement angle.
>   

Yes, that would be a good idea.

quoted text
>  - Move the optimized nop definitions (K7_NOPx etc) to the only place that 
>    cares - asm/x86/kernel/alternative.c. When we do things _dynamically_, 
>    it can actually make sense to pick a nop more precisely, but for this 
>    whole static thing it's just a pain.
>   

Yep.  We could run the p6 nops with an exception handler to see if the
cpu actually supports them or not.  And if not, just fall back to
something simple and good enough.

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