lkml.org 
[lkml]   [2013]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] x86 fixes for 3.11-rc2
On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
> Borislav Petkov <bp@alien8.de> 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.
--


\
 
 \ /
  Last update: 2013-07-20 20:01    [W:0.035 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site