linux-kernel - Re: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86

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: <6934b82d-db12-8a17-7dea-7bcbd4fe8566@intel.com>
Date:   Tue, 28 Jun 2022 14:01:40 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     "tarumizu.kohei@...itsu.com" <tarumizu.kohei@...itsu.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "mchehab+huawei@...nel.org" <mchehab+huawei@...nel.org>,
        "eugenis@...gle.com" <eugenis@...gle.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "pcc@...gle.com" <pcc@...gle.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "marcos@...a.pet" <marcos@...a.pet>,
        "marcan@...can.st" <marcan@...can.st>,
        "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
        "arnd@...db.de" <arnd@...db.de>, "ast@...nel.org" <ast@...nel.org>,
        "peter.chen@...nel.org" <peter.chen@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Paolo Valente <paolo.valente@...more.it>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and
 x86

On 6/28/22 13:20, Linus Walleij wrote:
> On Tue, Jun 28, 2022 at 5:47 PM Dave Hansen <dave.hansen@...el.com> wrote:
>> On 6/27/22 02:36, Linus Walleij wrote:
>>> The right way to solve this is to make the Linux kernel contain the
>>> necessary heuristics to identify which tasks and thus cores need this
>>> to improve efficiency and then apply it automatically.
>>
>> I agree in theory.  But, I also want a pony in theory.
>>
>> Any suggestions for how to do this in the real world?
> 
> Well if the knobs are exposed to userspace, how do people using
> these knobs know when to turn them? A profiler? perf? All that
> data is available to the kernel too.

They run their fortran app.  Change the MSRs.  Run it again.  See if it
simulated the nuclear weapon blast any faster or slower.  Rinse.  Repeat.

One thing that is missing from the changelog and cover letter here: On
x86, there's a 'wrmsr(1)' tool.  That took pokes at Model Specific
Registers (MSRs) via the /dev/cpu/X/msr interface.  That interface is a
very, very thinly-veiled wrapper around the WRMSR (WRite MSR) instruction.

In other words, on x86, our current interface allows userspace programs
to arbitrarily poke at our most sensitive hardware configuration
registers.  One of the most common reasons users have reported doing
this (we have pr_warn()ings about it) is controlling the prefetch hardware.

This interface would take a good chunk of the x86 wrmsr(1) audience and
convert them over to a less dangerous interface.  That's a win on x86.
We don't even *remotely* have line-of-sight for a generic solution for
the kernel to figure out a single "best" value for these registers.