linux-kernel - RE: [PATCH v4 0/8] 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] [day] [month] [year] [list]

Date:   Fri, 20 May 2022 08:31:49 +0000
From:   "tarumizu.kohei@...itsu.com" <tarumizu.kohei@...itsu.com>
To:     'Hector Martin' <marcan@...can.st>,
        "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>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "rafael@...nel.org" <rafael@...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>,
        "conor.dooley@...rochip.com" <conor.dooley@...rochip.com>,
        "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and
 x86

Thanks for the comment.

> If this is something to be tuned for specific applications, shouldn't it be a prctl or
> similar and part of process context, so different applications can use different
> settings (or even a single application depending on what it's doing)? Especially if
> writing those sysregs/MSRs is cheap.

> In particular, configuring things separately for different cores feels strange. You'd
> then have to pin applications to specific cores to get the benefits, and wouldn't be
> able to optimize for multiple applications running simultaneously that need
> different prefetch behavior if they share cores.

As you say, this is used for tuning specific applications.

I assume that users using this feature bind an application to a specific
core and use it exclusively. This is not only for pfctl, but also to
prevent performance from being affected by context switches, etc.

I agree that it is also useful to be able to control in the process
context. However, in this case, I think that it is sufficient if it can
be provided as a userspace interface which expresses the hardware
prefetch register directly, assuming the above usage.