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

[Rich Felker <dalias at libc dot org>]

On Mon, Aug 06, 2018 at 10:33:40AM -0300, Tulio Magno Quites Machado Filho wrote:
> Siddhesh Poyarekar <siddhesh@sourceware.org> writes:
> 
> > On 08/04/2018 02:03 AM, Tulio Magno Quites Machado Filho wrote:
> >>>> 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.
> >
> > OK, thanks for the clarification. It doesn't change my question though; 
> > is there a performance loss when you do a safe execution
> 
> Yes, for cacheable memory.  A safe execution uses only naturally aligned memory
> accesses and doesn't provide the best performance we have.
> 
> However an unsafe execution on cached inhibited memory is catastrophic because
> every naturally unaligned memory access generates an alignment interruption
> that is treated by the kernel, causing an even greater performance impact than
> a safe execution on cacheable memory.
> 
> > does it make sense to fix this in glibc?
> 
> IMHO, yes.  I haven't seen yet a good explanation on why userspace programs
> should not be using memcpy in these conditions, e.g. AFAIK, ISO C 11 does not
> prohibit this.

I'm not entirely clear on what "these conditions" are, but ISO C does
not allow memcpy to be used on volatile objects. It's not clear how
such objects would come into existence (presumably some sort of mmap),
but if they have weird properties about how you can perform accesses
on them, I think it's reasonable to argue that they have to be
volatile.

The compiler should not be generating calls to memcpy for volatile
objects; if it does that's a compiler bug.

Rich