Re: Put CPU-related tunables into a unique namespace?

[Carlos O'Donell <carlos at redhat dot com>]

On 07/11/2018 04:32 PM, Tulio Magno Quites Machado Filho wrote:
> Carlos O'Donell <carlos@redhat.com> writes:
> 
>> 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.
> 
> I have no strong opinion on this, but I do have some questions:
> 
> Do you plan to rename them now?
> 
> What would be the rules to get a tunable in/out a namespace?  In other words,
> what happens if a new tunable is supported by 2 machines?  e.g.
> glibc.elision.enable (I understand it's in another namespace, but it's the best
> example I have  :-) ).

There would be no rules.

You just discuss it on the list and get consensus to move the tunable.

For example the ".tune." namespace is somewhat useless, we *know* they
are tunables, why not just use 'glibc.x86.hwcaps'?

Can we have more than one namespace deep? I didn't think we could?
e.g. glibc.elision.x86.* (for all x86-related elision things).

My idea is that if it's a tunable specific to a single machine it should
be behind a machine namespace.

So as a starting thought:

* If a set of flags apply to 2 or more machines, we could move them into
  an arch-independent tunable namespace.

* Within an arch-independent namespace we might have another deeper list
  of arch namespaces e.g. glibc.elision.x86.* for x86 specific elision
  parameters that would otherwise have gone in glibc.elision.* if they
  were generic.

What do you think?

-- 
Cheers,
Carlos.