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:   Mon, 28 Jun 2021 19:49:04 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bill Wendling <morbo@...gle.com>,
        Bill Wendling <wcw@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Fangrui Song <maskray@...gle.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Jarmo Tiitto <jarmo.tiitto@...il.com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Will Deacon <will@...nel.org>
Subject: Re: [GIT PULL] Clang feature updates for v5.14-rc1

On Mon, Jun 28, 2021 at 12:32 PM Kees Cook <keescook@...omium.org> wrote:
>
> The big addition for this merge window is the core support for Clang's
> Profile Guided Optimization, which lets Clang build the kernel for
> improved performance when running specific kernel workloads. This
> currently covers only vmlinux, but module support is under active
> development. (Sami Tolvanen, Bill Wendling, Kees Cook, Jarmo Tiitto,
> Lukas Bulwahn)

Am I misreading this?

The PGO data seems to be done by using clang instrumentation, instead
of done sanely using sample data from a regular "perf" run?

That odd decision seems to not be documented anywhere, and it seems
odd and counter-productive, and causes all that odd special buffer
handling and that vmlinux.profraw file etc.

And it causes the kernel to be bigger and run slower.

The actual link to the clang pgo documentation even says that there is
already support for converting regular "perf" profile output to pgo
data, yet that model isn't actually used even though it appears vastly
superior.

Why use an inferior compiler instructmentation profile when we have
the much better tools?

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ