linux-kernel - Re: [PATCH 2/2] x86, Makefile: Add new generic x86-64 settings v2/v3/v4

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]

Date:   Wed, 18 Aug 2021 18:28:47 +0000
From:   Tor Vic <torvic9@...lbox.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "clang-built-linux@...glegroups.com" 
        <clang-built-linux@...glegroups.com>,
        "graysky@...hlinux.us" <graysky@...hlinux.us>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 2/2] x86, Makefile: Add new generic x86-64 settings
 v2/v3/v4



On 18.08.21 17:59, Borislav Petkov wrote:
> On Wed, Aug 18, 2021 at 05:08:40PM +0200, torvic9@...lbox.org wrote:
>> I ran some quick checks and benchmarks, and your doubts seem to be
>> justified. A 5.14-rc6 kernel compiled with the default 'generic' and
>> one built with 'x86-64-v3' even have the exact same uncompressed file
>> size. Benchmarks were inconclusive as well.
> 
> Lemme preface this with a IMHO:
> 
> Yeah, those -march machine-specific compiler switches don't really
> show any perf improvements for kernels because, well, if you look at
> the instruction stream a kernel executes, there's not really a whole
> lot left to optimize after -O2.
> 
> Also, the percentage of time a machine spends in the kernel should be a
> lot smaller (orders of magnitude) than in userspace - the operative word
> being *should* here :-) - so there really isn't anything to optimize.
> 
> Not to say that there aren't a gazillion other places in the kernel that
> could use more eyes and testing. ^Hint hint^

That's something I'd like to help with, hence my (not very good)
submissions.
You're one of the kernel colonels, so I'm happy to get some *useful*
feedback which enables noobs like me to get a better understanding of
the kernel stuff.
Also, credits to graysky because this is actually based on his work.

> 
> Thx.
>