From: "Luck, Tony" <tony.luck@intel.com>
To: "tarumizu.kohei@fujitsu.com" <tarumizu.kohei@fujitsu.com>,
'Linus Walleij' <linus.walleij@linaro.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
"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>,
"rafael@kernel.org" <rafael@kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"mchehab+huawei@kernel.org" <mchehab+huawei@kernel.org>,
"eugenis@google.com" <eugenis@google.com>,
"pcc@google.com" <pcc@google.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"marcos@orca.pet" <marcos@orca.pet>,
"marcan@marcan.st" <marcan@marcan.st>,
"nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
"conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"ast@kernel.org" <ast@kernel.org>,
"peter.chen@kernel.org" <peter.chen@kernel.org>,
"kuba@kernel.org" <kuba@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: RE: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86
Date: Tue, 28 Jun 2022 16:39:31 +0000 [thread overview]
Message-ID: <c2fb1376536d471f88b58ad82859a183@intel.com> (raw)
In-Reply-To: <OSBPR01MB203739DD69FB8C50990C356A80B89@OSBPR01MB2037.jpnprd01.prod.outlook.com>
>> 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.
>>
>> Putting it in userspace is making a human do a machines job which isn't
>> sustainable.
>>
>> By putting the heuristics in kernelspace Linux will improve performance also on
>> workloads the human operator didn't think of as the machine will detect them from
>> statictical or other behaviour patterns.
>
>In order to put the heuristics into kernelspace Linux, I think it
>necessary to consider the following two points.
>
>1) Which cores are tied with the process?
>This is different from the core on which the process can run. It
>probably need to combine some CPU resource limit to avoid affecting
>non-target processes.
>
>2) How to derive the value to set in the register?
>It is necessary to verify whether an appropriate set value can be
>derived using statistical information, etc. In addition, to prevent
>the cost of automatic derivation from exceeding the value that would
>be improved by it.
>
>I don't have a prospect for resolving these issues yet. I will
>continue these considerations.
Another approach would be to make the set of prefetch settings
a task attribute. Then set them in the context switch code when
the process is about to run on a CPU.
But that assumes you can cheaply change the attributes. If doing
so requires multiple MSR writes (on x86) it might be a non-starter.
-Tony
WARNING: multiple messages have this Message-ID (diff)
From: "Luck, Tony" <tony.luck@intel.com>
To: "tarumizu.kohei@fujitsu.com" <tarumizu.kohei@fujitsu.com>,
'Linus Walleij' <linus.walleij@linaro.org>
Cc: "rafael@kernel.org" <rafael@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"ast@kernel.org" <ast@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"will@kernel.org" <will@kernel.org>,
"mchehab+huawei@kernel.org" <mchehab+huawei@kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"eugenis@google.com" <eugenis@google.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>, "bp@alien8.de" <bp@alien8.de>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"pcc@google.com" <pcc@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"marcos@orca.pet" <marcos@orca.pet>,
Greg KH <gregkh@linuxfoundation.org>,
"peter.chen@kernel.org" <peter.chen@kernel.org>,
"marcan@marcan.st" <marcan@marcan.st>
Subject: RE: [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86
Date: Tue, 28 Jun 2022 16:39:31 +0000 [thread overview]
Message-ID: <c2fb1376536d471f88b58ad82859a183@intel.com> (raw)
In-Reply-To: <OSBPR01MB203739DD69FB8C50990C356A80B89@OSBPR01MB2037.jpnprd01.prod.outlook.com>
>> 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.
>>
>> Putting it in userspace is making a human do a machines job which isn't
>> sustainable.
>>
>> By putting the heuristics in kernelspace Linux will improve performance also on
>> workloads the human operator didn't think of as the machine will detect them from
>> statictical or other behaviour patterns.
>
>In order to put the heuristics into kernelspace Linux, I think it
>necessary to consider the following two points.
>
>1) Which cores are tied with the process?
>This is different from the core on which the process can run. It
>probably need to combine some CPU resource limit to avoid affecting
>non-target processes.
>
>2) How to derive the value to set in the register?
>It is necessary to verify whether an appropriate set value can be
>derived using statistical information, etc. In addition, to prevent
>the cost of automatic derivation from exceeding the value that would
>be improved by it.
>
>I don't have a prospect for resolving these issues yet. I will
>continue these considerations.
Another approach would be to make the set of prefetch settings
a task attribute. Then set them in the context switch code when
the process is about to run on a CPU.
But that assumes you can cheaply change the attributes. If doing
so requires multiple MSR writes (on x86) it might be a non-starter.
-Tony
_______________________________________________
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-06-28 16:44 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-07 12:05 [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86 Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-07 12:05 ` [PATCH v5 1/6] soc: fujitsu: Add hardware prefetch control driver for A64FX Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-10 13:20 ` Greg KH
2022-06-10 13:20 ` Greg KH
2022-06-07 12:05 ` [PATCH v5 2/6] soc: fujitsu: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-07 14:40 ` Randy Dunlap
2022-06-07 14:40 ` Randy Dunlap
2022-06-07 12:05 ` [PATCH v5 3/6] arm64: Create cache sysfs directory without ACPI PPTT for hardware prefetch control Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-07 12:05 ` [PATCH v5 4/6] x86: Add hardware prefetch control driver for x86 Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-07 12:05 ` [PATCH v5 5/6] x86: Add Kconfig/Makefile to build hardware prefetch control driver Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-07 14:40 ` Randy Dunlap
2022-06-07 14:40 ` Randy Dunlap
2022-06-08 6:11 ` tarumizu.kohei
2022-06-08 6:11 ` tarumizu.kohei
2022-06-07 12:05 ` [PATCH v5 6/6] docs: ABI: Add sysfs documentation interface of " Kohei Tarumizu
2022-06-07 12:05 ` Kohei Tarumizu
2022-06-10 13:07 ` [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86 Greg KH
2022-06-10 13:07 ` Greg KH
2022-06-14 11:55 ` tarumizu.kohei
2022-06-14 11:55 ` tarumizu.kohei
2022-06-14 12:34 ` 'Greg KH'
2022-06-14 12:34 ` 'Greg KH'
2022-06-17 9:20 ` tarumizu.kohei
2022-06-17 9:20 ` tarumizu.kohei
2022-06-27 9:36 ` Linus Walleij
2022-06-27 9:36 ` Linus Walleij
2022-06-28 13:55 ` tarumizu.kohei
2022-06-28 13:55 ` tarumizu.kohei
2022-06-28 16:39 ` Luck, Tony [this message]
2022-06-28 16:39 ` Luck, Tony
2022-06-30 5:24 ` tarumizu.kohei
2022-06-30 5:24 ` tarumizu.kohei
2022-06-28 15:46 ` Dave Hansen
2022-06-28 15:46 ` Dave Hansen
2022-06-28 20:20 ` Linus Walleij
2022-06-28 20:20 ` Linus Walleij
2022-06-28 21:01 ` Dave Hansen
2022-06-28 21:01 ` Dave Hansen
2022-06-28 21:17 ` Linus Walleij
2022-06-28 21:17 ` Linus Walleij
2022-06-30 9:43 ` tarumizu.kohei
2022-06-30 9:43 ` tarumizu.kohei
2022-06-10 13:48 ` Linus Walleij
2022-06-10 13:48 ` Linus Walleij
2022-06-17 9:06 ` tarumizu.kohei
2022-06-17 9:06 ` 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=c2fb1376536d471f88b58ad82859a183@intel.com \
--to=tony.luck@intel.com \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--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=kuba@kernel.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.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=peter.chen@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tarumizu.kohei@fujitsu.com \
--cc=tglx@linutronix.de \
--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.