glibc.cpu.cached_memopt (was Re: [PATCH] Rename the glibc.tune namespace to glibc.cpu)

[Tulio Magno Quites Machado Filho]

Siddhesh Poyarekar <siddhesh@sourceware.org> writes:

> On 07/17/2018 01:32 AM, Tulio Magno Quites Machado Filho wrote:
>> I'm not following your line of thought here:
>> 
>>   - glibc.cpu.hwcaps is specific to i386 and x86-64
>>   - glibc.cpu is specific to aarch64
>>   - glibc.cpu.cached_memopt is specific to powerpc, powerpc64 and powerpc64le
>> 
>> What am I missing?
>
> The difference is that glibc.cpu.name and glibc.cpu.hwcaps are 
> conceptually generic tunables, i.e. there is a reasonable chance that 
> couple of releases down the line another architecture may want to 
> provide tuning facility for CPUs by name or by HWCAPS.  The 
> cached_memopt one is not very clear to me and seems more like something 
> that is only useful on power8.

Maybe it isn't restricted only to powerpc:
https://sourceware.org/ml/libc-alpha/2018-08/msg00069.html

Obviously other machine maintainers may not be interested on cached_memopt,
but this thread helps me to explain why I was thinking cached_memopt was
generic.

>> Notice the optimization is not specific to a CPU, but specific to an user
>> scenario (cacheable memory).  In other words, the optimization can't be used
>> whenever PPC_FEATURE2_ARCH_2_07 because it could downgrade the performance when
>> cache-inhibited memory is being used.
>
> Ahh OK, I got thrown off by the fact that there's a separate routine for 
> it and assumed that it is Power8-specific.  I have a different concern 
> then; a tunable is process-wide so the cached_memopt tunable essentially 
> assumes that the entire process is using cache-inhibited memory.  Is 
> that a reasonable assumption?

It's the opposite.
When cached_memopt=1, it's assumed the process only uses cacheable memory.
If cached_memopt=0 (default value), nothing is assumed and a safe execution
is taken.

> 1. A new relocation that overlays on top of ifuncs and allows selection 
> of routines based on specific properties.  I have had this idea for a 
> while but no time to implement it and it has much more general scope 
> than memory type; for example memory alignment could also be a factor to 
> short-cut parts of string routines at compile time itself.  It does not 
> have the runtime flexibility of a tunable but is probably far more 
> configurable.

Sounds interesting.  Where are these properties coming from?

> 2. If there is a correlation to size then implement something similar to 
> the x86 temporal_threshold tunable.  This is probably just as good or 
> bad as setting a cached_memopt flag but has the effect of generalizing 
> what was a tunable.

I don't think this option would help in this case.
I can't correlate size to cache-inhibited memory.

-- 
Tulio Magno