Put CPU-related tunables into a unique namespace?

[Siddhesh Poyarekar]

On 07/12/2018 12:50 AM, Carlos O'Donell wrote:
> Should we use an arch namespace for CPU-related tunables?
> 
> e.g.
> 
> glibc.tune.x86.*
> glibc.tune.aarch64.*
> glibc.tune.power.*
> 
> We currently have:
> 
> glibc.tune.
> 	.hwcaps
> 	.cached_memopt
> 	.cpu
> 
> Which all look like they are "generic", but .hwcaps is
> x86 only, .cached_memopt is ppc only, and .cpu is aarch64
> only.

The idea of keeping the names arch-agnostic was to reduce the number of 
times one would have to rename tunables.  glibc.tune.cpu for example 
currently is used only by aarch64 but there is a legitimate future use 
case for another architecture to have tuning profiles based on CPU 
names.  A similar case can be made for hwcaps but not for cached_memopt. 
  cached_memopt looks like a powerpc-only case and should be named 
ppc_cached_memopt.

In fact, I don't see a strong enough justification for implementing this 
tunable in the first place; couldn't PPC_FEATURE2_ARCH_2_07 just be 
masked out from hwcaps to get the same effect?  There's 
glibc.tune.hwcap_mask for that.

> At least HJ has been using x86_* as a name prefix. Which
> is another alternative.
> 
> My preference is a unique namespace to let the machine
> maintainers add whatever they want in that namespace without
> collisions between CPUs.

My personal preference is to force machine maintainers to consider 
adding tunables in the generic space first and make tunables 
arch-specific only if it doesn't make sense for other architectures. 
That I hope would also enforce a more thorough discussion on why a 
tunable is required.

Siddhesh