Re: [GIT PULL] x86 fixes for 3.11-rc2

[Borislav Petkov]

On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
> Borislav Petkov <bp@xxxxxxxxx> wrote:
> > I don't think that matters because this is called only once on suspend.
> > Unless the cleaner assembly translates into a palpable speedup, which I
> > doubt.
> 
> I was thinking about code *size*, actually; I agree that speed is
> too small to measure.
> 
> Clean code (21 bytes):
>   4e:   b9 80 00 00 c0          mov    $0xc0000080,%ecx
>   53:   0f 32                   rdmsr  
>   55:   0f 30                   wrmsr  
>   57:   31 f6                   xor    %esi,%esi
>   59:   85 f6                   test   %esi,%esi
>   5b:   89 43 14                mov    %eax,0x14(%ebx)
>   5e:   89 53 18                mov    %edx,0x18(%ebx)
>   61:   75 04                   jne    67 <acpi_suspend_lowlevel+0x67>
> 
> Ugly code (50 bytes):

Right, that would matter maybe partially if the code was executed very
often. In that case, the probability of it fitting in one cacheline is
higher depending on alignment, and, you'd possibly save yourself loading
a second cacheline.

If it is 29 bytes bigger, than we have a higher probability for using a
second cacheline.

But again, I highly doubt even that would be noticeable. Especially on
modern uarches with very aggressive and smart branch prediction.

And since this is being called only once, you won't notice the
difference even with perf and specific instruction cache counters
enabled.

But what do I know - I'm always open to surprising workloads! :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/