This is the mail archive of the
mailing list for the glibc project.
Re: glibc.cpu.cached_memopt (was Re: [PATCH] Rename the glibc.tune namespace to glibc.cpu)
- From: Tulio Magno Quites Machado Filho <tuliom at ascii dot art dot br>
- To: Siddhesh Poyarekar <siddhesh at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Fri, 03 Aug 2018 17:33:36 -0300
- Subject: Re: glibc.cpu.cached_memopt (was Re: [PATCH] Rename the glibc.tune namespace to glibc.cpu)
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Siddhesh Poyarekar <email@example.com> 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:
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
>> 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
> 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
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.