Re: [PATCH v3] Reversing calculation of __x86_shared_non_temporal_threshold

[Carlos O'Donell <carlos@redhat.com>]

On 9/25/20 6:21 PM, Patrick McGehearty via Libc-alpha wrote:
> The __x86_shared_non_temporal_threshold determines when memcpy on x86
> uses non_temporal stores to avoid pushing other data out of the last
> level cache.
> 
> This patch proposes to revert the calculation change made by H.J. Lu's
> patch of June 2, 2017.
> 
> H.J. Lu's patch selected a threshold suitable for a single thread
> getting maximum performance. It was tuned using the single threaded
> large memcpy micro benchmark on an 8 core processor. The last change
> changes the threshold from using 3/4 of one thread's share of the
> cache to using 3/4 of the entire cache of a multi-threaded system
> before switching to non-temporal stores. Multi-threaded systems with
> more than a few threads are server-class and typically have many
> active threads. If one thread consumes 3/4 of the available cache for
> all threads, it will cause other active threads to have data removed
> from the cache. Two examples show the range of the effect. John
> McCalpin's widely parallel Stream benchmark, which runs in parallel
> and fetches data sequentially, saw a 20% slowdown with this patch on
> an internal system test of 128 threads. This regression was discovered
> when comparing OL8 performance to OL7.  An example that compares
> normal stores to non-temporal stores may be found at
> https://vgatherps.github.io/2018-09-02-nontemporal/.  A simple test
> shows performance loss of 400 to 500% due to a failure to use
> nontemporal stores. These performance losses are most likely to occur
> when the system load is heaviest and good performance is critical.
> 
> The tunable x86_non_temporal_threshold can be used to override the
> default for the knowledgable user who really wants maximum cache
> allocation to a single thread in a multi-threaded system.
> The manual entry for the tunable has been expanded to provide
> more information about its purpose.

Patrick,

Thank you for doing this work, and for all of the comments you made
downthread on the original posting.

I agree it is very easy to loose sight of the bigger "up and out"
picture of development when all you do is look at the core C library
performance for one process.

Your shared cautionary tales sparked various discussions within the
platform tools team here at Red Hat :-)

There is no silver bullet here, and the microbencmarks in glibc are
there to give us a starting point for a discussion.

I'm curious to know if you think there is some kind of balancing
microbenchmark we could write to show the effects of process-to-process
optimizations?

I'm happy if we all agree that the kind of "adjustments" you made
today will only be derived from an adaptive process involving customers,
applications, modern hardware, engineers, and the mixing of all of them
together to make such adjustments.

Thank you again.

-- 
Cheers,
Carlos.