From: "tarumizu.kohei@fujitsu.com" <tarumizu.kohei@fujitsu.com> To: 'Hector Martin' <marcan@marcan.st>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>, "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "rafael@kernel.org" <rafael@kernel.org>, "mchehab+huawei@kernel.org" <mchehab+huawei@kernel.org>, "eugenis@google.com" <eugenis@google.com>, "tony.luck@intel.com" <tony.luck@intel.com>, "pcc@google.com" <pcc@google.com>, "peterz@infradead.org" <peterz@infradead.org>, "marcos@orca.pet" <marcos@orca.pet>, "conor.dooley@microchip.com" <conor.dooley@microchip.com>, "nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "arnd@arndb.de" <arnd@arndb.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Date: Fri, 20 May 2022 08:31:49 +0000 [thread overview] Message-ID: <OSBPR01MB2037247D7482C9E0E0CFA2C380D39@OSBPR01MB2037.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <57184edb-8a04-b4bd-969b-bca152375d86@marcan.st> 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.
WARNING: multiple messages have this Message-ID (diff)
From: "tarumizu.kohei@fujitsu.com" <tarumizu.kohei@fujitsu.com> To: 'Hector Martin' <marcan@marcan.st>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "will@kernel.org" <will@kernel.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "mingo@redhat.com" <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>, "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>, "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "rafael@kernel.org" <rafael@kernel.org>, "mchehab+huawei@kernel.org" <mchehab+huawei@kernel.org>, "eugenis@google.com" <eugenis@google.com>, "tony.luck@intel.com" <tony.luck@intel.com>, "pcc@google.com" <pcc@google.com>, "peterz@infradead.org" <peterz@infradead.org>, "marcos@orca.pet" <marcos@orca.pet>, "conor.dooley@microchip.com" <conor.dooley@microchip.com>, "nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>, "linus.walleij@linaro.org" <linus.walleij@linaro.org>, "arnd@arndb.de" <arnd@arndb.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Date: Fri, 20 May 2022 08:31:49 +0000 [thread overview] Message-ID: <OSBPR01MB2037247D7482C9E0E0CFA2C380D39@OSBPR01MB2037.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <57184edb-8a04-b4bd-969b-bca152375d86@marcan.st> 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. _______________________________________________ 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-20 8:33 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 ` [PATCH v4 0/8] Add hardware prefetch control driver for A64FX and x86 Hector Martin 2022-05-19 8:29 ` Hector Martin 2022-05-20 8:31 ` tarumizu.kohei [this message] 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=OSBPR01MB2037247D7482C9E0E0CFA2C380D39@OSBPR01MB2037.jpnprd01.prod.outlook.com \ --to=tarumizu.kohei@fujitsu.com \ --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=marcan@marcan.st \ --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=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.