Put CPU-related tunables into a unique namespace?
Tulio Magno Quites Machado Filho
tuliom@linux.vnet.ibm.com
Wed Jul 11 20:33:00 GMT 2018
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 :-) ).
--
Tulio Magno
More information about the Libc-alpha
mailing list