From: Hector Martin <marcan@marcan.st> To: Kohei Tarumizu <tarumizu.kohei@fujitsu.com>, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, gregkh@linuxfoundation.org, rafael@kernel.org, mchehab+huawei@kernel.org, eugenis@google.com, tony.luck@intel.com, pcc@google.com, peterz@infradead.org, marcos@orca.pet, conor.dooley@microchip.com, nicolas.ferre@microchip.com, linus.walleij@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Date: Thu, 19 May 2022 17:29:39 +0900 [thread overview] Message-ID: <57184edb-8a04-b4bd-969b-bca152375d86@marcan.st> (raw) In-Reply-To: <20220518063032.2377351-1-tarumizu.kohei@fujitsu.com> On 18/05/2022 15.30, Kohei Tarumizu wrote: > This patch series add sysfs interface to control CPU's hardware > prefetch behavior for performance tuning from userspace for the > processor A64FX and x86 (on supported CPU). > [snip] > In pattern A, a change of dist at L1 has a larger effect. On the other > hand, in pattern B, the change of dist at L2 has a larger effect. > As described above, the optimal dist combination depends on the > characteristics of the application. Therefore, such a sysfs interface > is useful for performance tuning. 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. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
WARNING: multiple messages have this Message-ID (diff)
From: Hector Martin <marcan@marcan.st> To: Kohei Tarumizu <tarumizu.kohei@fujitsu.com>, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, gregkh@linuxfoundation.org, rafael@kernel.org, mchehab+huawei@kernel.org, eugenis@google.com, tony.luck@intel.com, pcc@google.com, peterz@infradead.org, marcos@orca.pet, conor.dooley@microchip.com, nicolas.ferre@microchip.com, linus.walleij@linaro.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Date: Thu, 19 May 2022 17:29:39 +0900 [thread overview] Message-ID: <57184edb-8a04-b4bd-969b-bca152375d86@marcan.st> (raw) In-Reply-To: <20220518063032.2377351-1-tarumizu.kohei@fujitsu.com> On 18/05/2022 15.30, Kohei Tarumizu wrote: > This patch series add sysfs interface to control CPU's hardware > prefetch behavior for performance tuning from userspace for the > processor A64FX and x86 (on supported CPU). > [snip] > In pattern A, a change of dist at L1 has a larger effect. On the other > hand, in pattern B, the change of dist at L2 has a larger effect. > As described above, the optimal dist combination depends on the > characteristics of the application. Therefore, such a sysfs interface > is useful for performance tuning. 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. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-05-19 8:30 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-18 6:30 [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 6:30 ` [PATCH v4 1/8] drivers: base: Add hardware prefetch control core driver Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 7:09 ` Greg KH 2022-05-18 7:09 ` Greg KH 2022-05-18 12:38 ` tarumizu.kohei 2022-05-18 12:38 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 2/8] drivers: base: Add Kconfig/Makefile to build " Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 7:04 ` Greg KH 2022-05-18 7:04 ` Greg KH 2022-05-20 6:42 ` tarumizu.kohei 2022-05-20 6:42 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 3/8] soc: fujitsu: Add hardware prefetch control support for A64FX Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 7:10 ` Greg KH 2022-05-18 7:10 ` Greg KH 2022-05-20 7:06 ` tarumizu.kohei 2022-05-20 7:06 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 4/8] soc: fujitsu: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 6:30 ` [PATCH v4 5/8] arm64: Create cache sysfs directory without ACPI PPTT for hardware prefetch control Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 7:09 ` Greg KH 2022-05-18 7:09 ` Greg KH 2022-05-20 7:00 ` tarumizu.kohei 2022-05-20 7:00 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 6/8] x86: Add hardware prefetch control support for x86 Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 6:43 ` Greg KH 2022-05-18 6:43 ` Greg KH 2022-05-20 6:30 ` tarumizu.kohei 2022-05-20 6:30 ` tarumizu.kohei 2022-05-18 6:44 ` Greg KH 2022-05-18 6:44 ` Greg KH 2022-05-20 6:40 ` tarumizu.kohei 2022-05-20 6:40 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 7/8] x86: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-18 6:43 ` Greg KH 2022-05-18 6:43 ` Greg KH 2022-05-20 6:35 ` tarumizu.kohei 2022-05-20 6:35 ` tarumizu.kohei 2022-05-18 6:30 ` [PATCH v4 8/8] docs: ABI: Add sysfs documentation interface of " Kohei Tarumizu 2022-05-18 6:30 ` Kohei Tarumizu 2022-05-19 8:29 ` Hector Martin [this message] 2022-05-19 8:29 ` [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Hector Martin 2022-05-20 8:31 ` tarumizu.kohei 2022-05-20 8:31 ` tarumizu.kohei
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=57184edb-8a04-b4bd-969b-bca152375d86@marcan.st \ --to=marcan@marcan.st \ --cc=arnd@arndb.de \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=conor.dooley@microchip.com \ --cc=dave.hansen@linux.intel.com \ --cc=eugenis@google.com \ --cc=gregkh@linuxfoundation.org \ --cc=hpa@zytor.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marcos@orca.pet \ --cc=mchehab+huawei@kernel.org \ --cc=mingo@redhat.com \ --cc=nicolas.ferre@microchip.com \ --cc=pcc@google.com \ --cc=peterz@infradead.org \ --cc=rafael@kernel.org \ --cc=tarumizu.kohei@fujitsu.com \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=will@kernel.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.