From: 'Greg KH' <gregkh@linuxfoundation.org>
To: "tarumizu.kohei@fujitsu.com" <tarumizu.kohei@fujitsu.com>
Cc: "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>,
"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>,
"marcan@marcan.st" <marcan@marcan.st>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"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, 14 Jun 2022 14:34:43 +0200 [thread overview]
Message-ID: <YqiAY689pOJbHKUd@kroah.com> (raw)
In-Reply-To: <OSBPR01MB203749DA00C7BEE5741AFEB980AA9@OSBPR01MB2037.jpnprd01.prod.outlook.com>
On Tue, Jun 14, 2022 at 11:55:39AM +0000, tarumizu.kohei@fujitsu.com wrote:
> Thanks for the comment.
>
> > Why does userspace want to even do this?
>
> This is because the optimal settings may differ from application to
> application.
That's not ok. Linux is a "general purpose" operating system and needs
to work well for all applications. Doing application-specific-tuning
based on the specific hardware like this is a nightmare for users, and
will be for you as you will now have to support this specific model to
work correctly on all future kernel releases for the next 20+ years.
Are you willing to do that?
> Examples of performance improvements for applications with simple
> memory access characteristics are described in [merit] section.
> However, some applications have complex characteristics, so it is
> difficult to predict if an application will improve without actually
> trying it out.
Then perhaps it isn't anything that they should try out :)
Shouldn't the kernel know how the application works (based on the
resources it asks for) and tune itself based on that automatically?
If not, how is a user supposed to know how to do this?
> This is not necessary for all applications. However, I want to provide
> as a minimal interface that can be used by those who want to improve
> their application even a little.
>
> > How will they do this?
>
> I assume to be used to tune a specific core and execute an application
> on that core. The execution example is as follows.
>
> 1) The user tunes the parameters of a specific core before executing
> the program.
>
> ```
> # echo 1024 > /sys/devices/system/cpu/cpu12/cache/index0/prefetch_control/stream_detect_prefetcher_dist
> # echo 1024 > /sys/devices/system/cpu/cpu12/cache/index2/prefetch_control/stream_detect_prefetcher_dist
> # echo 1024 > /sys/devices/system/cpu/cpu13/cache/index0/prefetch_control/stream_detect_prefetcher_dist
> # echo 1024 > /sys/devices/system/cpu/cpu13/cache/index2/prefetch_control/stream_detect_prefetcher_dist
> ```
What is "1024" here? Where is any of this documented? And why these
specific sysfs files and not others?
> 2) Execute the program bound to the target core.
>
> ```
> # taskset -c 12-13 a.out
> ```
>
> If the interface is exposed, the user can develop a library to execute
> 1) and 2) operation instead.
If you have no such user today, nor a library, how do you know any of
this works well? And again, how will you support this going forward?
Or is this specific api only going to be for one specific piece of
hardware and never any future ones?
> > What programs will do this?
>
> It is assumed to be used by programs that execute many continuous
> memory access. It may be useful for other applications, but I can't
> explain them in detail right away.
So you haven't tested this on any real applications? We need real users
before being able to add new apis. Otherwise we can just remove the
apis :)
> > And why isn't just automatic and why does this hardware require manual
> > intervention to work properly?
>
> It is difficult for the hardware to determine the optimal parameters
> in advance. Therefore, I think that the register is provided to change
> the behavior of the hardware.
Kernel programming for a general purpose operating system is hard, but
it is possible :)
good luck!
greg k-h
next prev parent reply other threads:[~2022-06-14 12:40 UTC|newest]
Thread overview: 26+ 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 ` [PATCH v5 1/6] soc: fujitsu: Add hardware prefetch control driver for A64FX Kohei Tarumizu
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 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 ` [PATCH v5 4/6] x86: Add hardware prefetch control driver for x86 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 14:40 ` Randy Dunlap
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-10 13:07 ` [PATCH v5 0/6] Add hardware prefetch control driver for A64FX and x86 Greg KH
2022-06-14 11:55 ` tarumizu.kohei
2022-06-14 12:34 ` 'Greg KH' [this message]
2022-06-17 9:20 ` tarumizu.kohei
2022-06-27 9:36 ` Linus Walleij
2022-06-28 13:55 ` tarumizu.kohei
2022-06-28 16:39 ` Luck, Tony
2022-06-30 5:24 ` tarumizu.kohei
2022-06-28 15:46 ` Dave Hansen
2022-06-28 20:20 ` Linus Walleij
2022-06-28 21:01 ` Dave Hansen
2022-06-28 21:17 ` Linus Walleij
2022-06-30 9:43 ` tarumizu.kohei
2022-06-10 13:48 ` Linus Walleij
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=YqiAY689pOJbHKUd@kroah.com \
--to=gregkh@linuxfoundation.org \
--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=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox