This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 07/12/2018 10:17 AM, Siddhesh Poyarekar wrote:
> 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.

OK, so a couple of questions for you?

* Should '.tune.' be removed considering these are *tunables*?

* You suggest we try to implement generic tunables first, discuss why
  it should not be generic, and then only then put it in an arch-specific
  tunables?

* Do you have a preferences for (a) or (b)?
  https://www.sourceware.org/ml/libc-alpha/2018-07/msg00324.html

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]