[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mtgftov3.ffs@tglx>
Date: Wed, 20 Apr 2022 23:40:48 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Kohei Tarumizu <tarumizu.kohei@...itsu.com>,
catalin.marinas@....com, will@...nel.org, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, fenghua.yu@...el.com,
reinette.chatre@...el.com
Cc: tarumizu.kohei@...itsu.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v3 1/9] drivers: base: Add hardware prefetch control
core driver
Kohei,
Cc+: driver core maintainers
On Wed, Apr 20 2022 at 12:02, Kohei Tarumizu wrote:
> +static const char dist_auto_string[] = "auto";
> +static const char strength_strong_string[] = "strong";
> +static const char strength_weak_string[] = "weak";
This is A64FX specific.
> +pfctl_enable_show(hardware_prefetcher, HWPF_ENABLE);
> +pfctl_enable_show(ip_prefetcher, IPPF_ENABLE);
> +pfctl_enable_show(adjacent_cache_line_prefetcher, ACLPF_ENABLE);
This is x86 specific.
> +pfctl_enable_show(stream_detect_prefetcher, SDPF_ENABLE);
This is A64FX specific.
So why is this in generic code and why needs x86 to populate the A64FX
bits and make them invisible? Same the other way round.
Now imagine a few other [sub]architectures come around and add their
specific prefetcher control knobs, strings and whatever. That's going to
be unmaintainable in no time.
This is not comparable to the cache attributes where the architectures
share a significant amount of subsets. You just demonstrated that X86
and A64FX share not even a single entry.
The core code should provide infrastructure to manage the
[sub]architecture specific control files at different cache levels.
Not more not less.
Thanks,
tglx
Powered by blists - more mailing lists