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

[Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>]

On Thu, Jul 12, 2018 at 2:10 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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'?

 I would prefer glibc.<archname>.<tunable> than have the additional tune there
as it doesn't seem to add anything at the top level.

>
> 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.

And are largely semantically equivalent ? This feels to me no
different to whether
we put command line options in the -f space or the -m space in gcc to use
a gcc analogy.

>
> * 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.

Using your example above, having glibc.elision.x86 and
glibc.x86.elision_params also seems a recipe for mistyping things and
confusion on the
keyboard. Would it be simpler to just say glibc.elision.* is all
common stuff and glibc.<arch>.elision.* and have a correlation that
the suboption
in the <arch> namespace is the same as the top level common name ?

Having said that, I don't feel strongly either way TBH.

Ramana

>
> What do you think?
>
> --
> Cheers,
> Carlos.