All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.