From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by sourceware.org (Postfix) with ESMTPS id A4FDD3858422 for ; Mon, 14 Aug 2023 23:00:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A4FDD3858422 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x2a.google.com with SMTP id 586e51a60fabf-1bba7717d3bso3655845fac.1 for ; Mon, 14 Aug 2023 16:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692053998; x=1692658798; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uNCYTkxMZkapNUWHQH7ukA2+x95n568+hvVgqTij+LA=; b=mBjstA/Rcx9bhSg2IxdY02UFwfNuu86hMGTsLmXrLh2k8iqfiLNy/BUVGUJJy6Xn8K jhYra8xrVziozHWvmVyl19N9PJhxHEhrVMb0AojsWPMMCcb3p1/fXbsVNcBxYP2eCj5F v6nevG2iyceau19qoR5UMcC9XNm55c6plv2DtzGAZpLoBnjiV61kOl/vFzQoq8F1u8Z9 MGkR/g0anVrYNAZE6ldhVXI3Uy5J+xgE4U78b62k69oWDbNCbQQsM+BjT+qdM0kqWiw+ jTYT5wTTkrPGVAjVuqjQOBDZNK8iTinvbGDEqDXvu6M1A57L1zclFa77FOLX85vM4G82 FKtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692053998; x=1692658798; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uNCYTkxMZkapNUWHQH7ukA2+x95n568+hvVgqTij+LA=; b=E5OtvDkuqF4v7tOW/AO6qXYWzgtbVNrp9kyfIVEs9PFmI47ZiIlA7asPgV/nVw2hqO q3FzgwzL8yOJYj8gz0lxz15EgAS08kmpPHCPoa0XpTL6OjFFfJPfCQCzqGg03kDkLZE1 HuCbVFmzdUWeHXatETJp2u9On3/6wJG2zojn8ly6/xfqBqrhShgTtSQ5eikGLpZ/yGD1 4zdeTfHAsM9kXiCvUa3/ArBdMQO7Nsy415huwn1V/gP+DozQZf+nEtAn22vtR8iOaZeS 3ZWYMARF7vwXeICo8jGbxTHlAoEwxsGQQdM2CCwvMnFJNwEixKbzmVkzrlOPm9odYiHT AydA== X-Gm-Message-State: AOJu0YyW2uBtkzpr5sV49aIbrsSXM/G9XugoAt6F4EdZnLd+YT2biLko xiTf0hFA4ayCsDb5vco4dgbPAmA54O8eJC+E6EVQNMzhVFY= X-Google-Smtp-Source: AGHT+IEIo8D3yYW+y5T1gKHaygb4YWgqeVSgWSpaPrmkosk7YK123QC1YMalH/BUD86FkxqxUMIiSsTYifHlT3ouxMI= X-Received: by 2002:a05:6870:b4ac:b0:1bf:8c9a:9a2c with SMTP id y44-20020a056870b4ac00b001bf8c9a9a2cmr10812381oap.15.1692053998541; Mon, 14 Aug 2023 15:59:58 -0700 (PDT) MIME-Version: 1.0 References: <20230424050329.1501348-1-goldstein.w.n@gmail.com> <20230607181803.4154764-1-goldstein.w.n@gmail.com> In-Reply-To: <20230607181803.4154764-1-goldstein.w.n@gmail.com> From: Noah Goldstein Date: Mon, 14 Aug 2023 18:00:16 -0500 Message-ID: Subject: Re: [PATCH v11 1/3] x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4` To: libc-alpha@sourceware.org Cc: hjl.tools@gmail.com, carlos@systemhalted.org, DJ Delorie , "Carlos O'Donell" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jun 7, 2023 at 1:18=E2=80=AFPM Noah Goldstein wrote: > > Current `non_temporal_threshold` set to roughly '3/4 * sizeof_L3 / > ncores_per_socket'. This patch updates that value to roughly > 'sizeof_L3 / 4` > > The original value (specifically dividing the `ncores_per_socket`) was > done to limit the amount of other threads' data a `memcpy`/`memset` > could evict. > > Dividing by 'ncores_per_socket', however leads to exceedingly low > non-temporal thresholds and leads to using non-temporal stores in > cases where REP MOVSB is multiple times faster. > > Furthermore, non-temporal stores are written directly to main memory > so using it at a size much smaller than L3 can place soon to be > accessed data much further away than it otherwise could be. As well, > modern machines are able to detect streaming patterns (especially if > REP MOVSB is used) and provide LRU hints to the memory subsystem. This > in affect caps the total amount of eviction at 1/cache_associativity, > far below meaningfully thrashing the entire cache. > > As best I can tell, the benchmarks that lead this small threshold > where done comparing non-temporal stores versus standard cacheable > stores. A better comparison (linked below) is to be REP MOVSB which, > on the measure systems, is nearly 2x faster than non-temporal stores > at the low-end of the previous threshold, and within 10% for over > 100MB copies (well past even the current threshold). In cases with a > low number of threads competing for bandwidth, REP MOVSB is ~2x faster > up to `sizeof_L3`. > > The divisor of `4` is a somewhat arbitrary value. From benchmarks it > seems Skylake and Icelake both prefer a divisor of `2`, but older CPUs > such as Broadwell prefer something closer to `8`. This patch is meant > to be followed up by another one to make the divisor cpu-specific, but > in the meantime (and for easier backporting), this patch settles on > `4` as a middle-ground. > > Benchmarks comparing non-temporal stores, REP MOVSB, and cacheable > stores where done using: > https://github.com/goldsteinn/memcpy-nt-benchmarks > > Sheets results (also available in pdf on the github): > https://docs.google.com/spreadsheets/d/e/2PACX-1vS183r0rW_jRX6tG_E90m9qVu= FiMbRIJvi5VAE8yYOvEOIEEc3aSNuEsrFbuXw5c3nGboxMmrupZD7K/pubhtml > Reviewed-by: DJ Delorie > Reviewed-by: Carlos O'Donell > --- > sysdeps/x86/dl-cacheinfo.h | 70 +++++++++++++++++++++++--------------- > 1 file changed, 43 insertions(+), 27 deletions(-) > > diff --git a/sysdeps/x86/dl-cacheinfo.h b/sysdeps/x86/dl-cacheinfo.h > index 877e73d700..3bd3b3ec1b 100644 > --- a/sysdeps/x86/dl-cacheinfo.h > +++ b/sysdeps/x86/dl-cacheinfo.h > @@ -407,7 +407,7 @@ handle_zhaoxin (int name) > } > > static void > -get_common_cache_info (long int *shared_ptr, unsigned int *threads_ptr, > +get_common_cache_info (long int *shared_ptr, long int * shared_per_threa= d_ptr, unsigned int *threads_ptr, > long int core) > { > unsigned int eax; > @@ -426,6 +426,7 @@ get_common_cache_info (long int *shared_ptr, unsigned= int *threads_ptr, > unsigned int family =3D cpu_features->basic.family; > unsigned int model =3D cpu_features->basic.model; > long int shared =3D *shared_ptr; > + long int shared_per_thread =3D *shared_per_thread_ptr; > unsigned int threads =3D *threads_ptr; > bool inclusive_cache =3D true; > bool support_count_mask =3D true; > @@ -441,6 +442,7 @@ get_common_cache_info (long int *shared_ptr, unsigned= int *threads_ptr, > /* Try L2 otherwise. */ > level =3D 2; > shared =3D core; > + shared_per_thread =3D core; > threads_l2 =3D 0; > threads_l3 =3D -1; > } > @@ -597,29 +599,28 @@ get_common_cache_info (long int *shared_ptr, unsign= ed int *threads_ptr, > } > else > { > -intel_bug_no_cache_info: > - /* Assume that all logical threads share the highest cache > - level. */ > - threads > - =3D ((cpu_features->features[CPUID_INDEX_1].cpuid.ebx >> 16) > - & 0xff); > - } > - > - /* Cap usage of highest cache level to the number of supported > - threads. */ > - if (shared > 0 && threads > 0) > - shared /=3D threads; > + intel_bug_no_cache_info: > + /* Assume that all logical threads share the highest cache > + level. */ > + threads =3D ((cpu_features->features[CPUID_INDEX_1].cpuid.ebx >= > 16) > + & 0xff); > + > + /* Get per-thread size of highest level cache. */ > + if (shared_per_thread > 0 && threads > 0) > + shared_per_thread /=3D threads; > + } > } > > /* Account for non-inclusive L2 and L3 caches. */ > if (!inclusive_cache) > { > if (threads_l2 > 0) > - core /=3D threads_l2; > + shared_per_thread +=3D core / threads_l2; > shared +=3D core; > } > > *shared_ptr =3D shared; > + *shared_per_thread_ptr =3D shared_per_thread; > *threads_ptr =3D threads; > } > > @@ -629,6 +630,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features) > /* Find out what brand of processor. */ > long int data =3D -1; > long int shared =3D -1; > + long int shared_per_thread =3D -1; > long int core =3D -1; > unsigned int threads =3D 0; > unsigned long int level1_icache_size =3D -1; > @@ -649,6 +651,7 @@ dl_init_cacheinfo (struct cpu_features *cpu_features) > data =3D handle_intel (_SC_LEVEL1_DCACHE_SIZE, cpu_features); > core =3D handle_intel (_SC_LEVEL2_CACHE_SIZE, cpu_features); > shared =3D handle_intel (_SC_LEVEL3_CACHE_SIZE, cpu_features); > + shared_per_thread =3D shared; > > level1_icache_size > =3D handle_intel (_SC_LEVEL1_ICACHE_SIZE, cpu_features); > @@ -672,13 +675,14 @@ dl_init_cacheinfo (struct cpu_features *cpu_feature= s) > level4_cache_size > =3D handle_intel (_SC_LEVEL4_CACHE_SIZE, cpu_features); > > - get_common_cache_info (&shared, &threads, core); > + get_common_cache_info (&shared, &shared_per_thread, &threads, core= ); > } > else if (cpu_features->basic.kind =3D=3D arch_kind_zhaoxin) > { > data =3D handle_zhaoxin (_SC_LEVEL1_DCACHE_SIZE); > core =3D handle_zhaoxin (_SC_LEVEL2_CACHE_SIZE); > shared =3D handle_zhaoxin (_SC_LEVEL3_CACHE_SIZE); > + shared_per_thread =3D shared; > > level1_icache_size =3D handle_zhaoxin (_SC_LEVEL1_ICACHE_SIZE); > level1_icache_linesize =3D handle_zhaoxin (_SC_LEVEL1_ICACHE_LINES= IZE); > @@ -692,13 +696,14 @@ dl_init_cacheinfo (struct cpu_features *cpu_feature= s) > level3_cache_assoc =3D handle_zhaoxin (_SC_LEVEL3_CACHE_ASSOC); > level3_cache_linesize =3D handle_zhaoxin (_SC_LEVEL3_CACHE_LINESIZ= E); > > - get_common_cache_info (&shared, &threads, core); > + get_common_cache_info (&shared, &shared_per_thread, &threads, core= ); > } > else if (cpu_features->basic.kind =3D=3D arch_kind_amd) > { > data =3D handle_amd (_SC_LEVEL1_DCACHE_SIZE); > core =3D handle_amd (_SC_LEVEL2_CACHE_SIZE); > shared =3D handle_amd (_SC_LEVEL3_CACHE_SIZE); > + shared_per_thread =3D shared; > > level1_icache_size =3D handle_amd (_SC_LEVEL1_ICACHE_SIZE); > level1_icache_linesize =3D handle_amd (_SC_LEVEL1_ICACHE_LINESIZE)= ; > @@ -715,6 +720,9 @@ dl_init_cacheinfo (struct cpu_features *cpu_features) > if (shared <=3D 0) > /* No shared L3 cache. All we have is the L2 cache. */ > shared =3D core; > + > + if (shared_per_thread <=3D 0) > + shared_per_thread =3D shared; > } > > cpu_features->level1_icache_size =3D level1_icache_size; > @@ -730,17 +738,25 @@ dl_init_cacheinfo (struct cpu_features *cpu_feature= s) > cpu_features->level3_cache_linesize =3D level3_cache_linesize; > cpu_features->level4_cache_size =3D level4_cache_size; > > - /* The default setting for the non_temporal threshold is 3/4 of one > - thread's share of the chip's cache. For most Intel and AMD processo= rs > - with an initial release date between 2017 and 2020, a thread's typi= cal > - share of the cache is from 500 KBytes to 2 MBytes. Using the 3/4 > - threshold leaves 125 KBytes to 500 KBytes of the thread's data > - in cache after a maximum temporal copy, which will maintain > - in cache a reasonable portion of the thread's stack and other > - active data. If the threshold is set higher than one thread's > - share of the cache, it has a substantial risk of negatively > - impacting the performance of other threads running on the chip. */ > - unsigned long int non_temporal_threshold =3D shared * 3 / 4; > + /* The default setting for the non_temporal threshold is 1/4 of size > + of the chip's cache. For most Intel and AMD processors with an > + initial release date between 2017 and 2023, a thread's typical > + share of the cache is from 18-64MB. Using the 1/4 L3 is meant to > + estimate the point where non-temporal stores begin out-competing > + REP MOVSB. As well the point where the fact that non-temporal > + stores are forced back to main memory would already occurred to the > + majority of the lines in the copy. Note, concerns about the > + entire L3 cache being evicted by the copy are mostly alleviated > + by the fact that modern HW detects streaming patterns and > + provides proper LRU hints so that the maximum thrashing > + capped at 1/associativity. */ > + unsigned long int non_temporal_threshold =3D shared / 4; > + /* If no ERMS, we use the per-thread L3 chunking. Normal cacheable sto= res run > + a higher risk of actually thrashing the cache as they don't have a = HW LRU > + hint. As well, their performance in highly parallel situations is > + noticeably worse. */ > + if (!CPU_FEATURE_USABLE_P (cpu_features, ERMS)) > + non_temporal_threshold =3D shared_per_thread * 3 / 4; > /* SIZE_MAX >> 4 because memmove-vec-unaligned-erms right-shifts the v= alue of > 'x86_non_temporal_threshold' by `LOG_4X_MEMCPY_THRESH` (4) and it i= s best > if that operation cannot overflow. Minimum of 0x4040 (16448) becaus= e the > -- > 2.34.1 > Hi All, I want to backport this series (minus CPUID codes) too 2.28 - 2.37 The patches I want to backport are: 1/4 ``` commit af992e7abdc9049714da76cae1e5e18bc4838fb8 Author: Noah Goldstein Date: Wed Jun 7 13:18:01 2023 -0500 x86: Increase `non_temporal_threshold` to roughly `sizeof_L3 / 4` ``` 2/4 ``` commit 47f747217811db35854ea06741be3685e8bbd44d Author: Noah Goldstein Date: Mon Jul 17 23:14:33 2023 -0500 x86: Fix slight bug in `shared_per_thread` cache size calculation. ``` 3/4 ``` commit 8b9a0af8ca012217bf90d1dc0694f85b49ae09da Author: Noah Goldstein Date: Tue Jul 18 10:27:59 2023 -0500 [PATCH v1] x86: Use `3/4*sizeof(per-thread-L3)` as low bound for NT threshold. ``` 4/4 ``` commit 084fb31bc2c5f95ae0b9e6df4d3cf0ff43471ede (origin/master, origin/HEAD, master) Author: Noah Goldstein Date: Thu Aug 10 19:28:24 2023 -0500 x86: Fix incorrect scope of setting `shared_per_thread` [BZ# 30745] ``` The proposed patches are at: https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-28 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-29 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-30 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-31 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-32 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-33 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-34 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-35 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-36 https://gitlab.com/x86-glibc/glibc/-/commits/users/goldsteinn/backport-37 I know the protocol is not to normally backport optimizations, but I'd argu= e these are closer to bug fixes for a severe misconfiguration than a proper optimization series. As well, the risk of introducing a correctness relate= d bug is exceedingly low. Typically the type of optimization patch this is discouraged are the ones that actually change a particular function. I.e if these fixes where direct= ly to the memmove implementation. These patches, however, don't touch any of the memmove code itself, and are just re-tuning a value used by memmove which seems categorically different. The value also only informs memmove strategy. If these patches turn out to be deeply buggy and set the new threshold incorrectly, the blowback is limited to a bad performance (which we already have), and is extremely unlikely to affect correctness in any way. Thoughts?