This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Put CPU-related tunables into a unique namespace?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 12 Jul 2018 11:31:49 -0400
- Subject: Re: Put CPU-related tunables into a unique namespace?
- References: <0b01d5de-29c8-ba7f-06fb-8048458df0e3@redhat.com> <0732d027-b9b7-5621-75fb-d1a282883a34@gotplt.org>
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.