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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130720165555.GB13759@pd.tnic>
Date:	Sat, 20 Jul 2013 18:55:55 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	George Spelvin <linux@...izon.com>
Cc:	hpa@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] x86 fixes for 3.11-rc2

On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
> Borislav Petkov <bp@...en8.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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/