From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id C16983950C39 for ; Wed, 23 Sep 2020 20:23:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C16983950C39 Received: by mail-lf1-x143.google.com with SMTP id b12so1297094lfp.9 for ; Wed, 23 Sep 2020 13:23:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Amcp6EAxpH3RV0XK4PR09Q+I+8DlcgLu/97CHoagvv0=; b=nOUdXoPzExCgAKah2uAbc6Bzq0Vlx76JXBVG8xxJovBhkoa6+il/NEHDWe0xfKM7e9 pNSM04Oz00MWBtUc1iSiuAxKjyfaI3vD8+IgAsYagKAHTNxAmtp1ED7RPrFMzuP6ulWc vaMRPls1oK9B4VTjP8i0bH9+m9otygh6lGsbTDD3YmMqjuL0F2lLf/nzM4FGy4L9ibsy XP7WCiXJ54p3aWE5YTLgZPnYWKm+FyxFXGRNn21WeYgQWcOPjEh6EJbfcnDDx3cGg6KZ s+HT1HTmzAHCcJydr0TSo2a15DaSCRMUGNQGUqryWrVN6aMAqTlzlRWU5v2XYbo+cIbC xyiQ== X-Gm-Message-State: AOAM5315nuUyNG8q3m92L3UR/Ehf2331yVQ2hK+FbDrAoxrCcufDTUAJ /5mxmxVS3jlUNOrBjm3dCAddctELjjuBrebGSVg= X-Google-Smtp-Source: ABdhPJz5Xl3sgQfeVknz7odNeQlwoT9rVBgKzsyjL/LlZ88hFgH3/6wpjKYF2RJ853/c7NMDehn873DpVrmzQHughX0= X-Received: by 2002:a19:cb96:: with SMTP id b144mr538287lfg.143.1600892625554; Wed, 23 Sep 2020 13:23:45 -0700 (PDT) MIME-Version: 1.0 References: <1600891781-9272-1-git-send-email-patrick.mcgehearty@oracle.com> In-Reply-To: <1600891781-9272-1-git-send-email-patrick.mcgehearty@oracle.com> From: "H.J. Lu" Date: Wed, 23 Sep 2020 13:23:09 -0700 Message-ID: Subject: Re: [PATCH v2] Reversing calculation of __x86_shared_non_temporal_threshold To: Patrick McGehearty Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.3 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 20:23:48 -0000 On Wed, Sep 23, 2020 at 1:10 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. > > modified: sysdeps/x86/cacheinfo.c > modified: manual/tunables.texi > --- > manual/tunables.texi | 6 +++++- > sysdeps/x86/cacheinfo.c | 12 +++++++----- > 2 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/manual/tunables.texi b/manual/tunables.texi > index b6bb54d..94d4fbd 100644 > --- a/manual/tunables.texi > +++ b/manual/tunables.texi > @@ -364,7 +364,11 @@ set shared cache size in bytes for use in memory and string routines. > > @deftp Tunable glibc.tune.x86_non_temporal_threshold > The @code{glibc.tune.x86_non_temporal_threshold} tunable allows the user > -to set threshold in bytes for non temporal store. > +to set threshold in bytes for non temporal store. Non temporal stores > +give a hint to the hardware to move data directly to memory without > +displacing other data from the cache. This tunable is used by some > +platforms to determine when to use non temporal stores in operations > +like memmove and memcpy. > > This tunable is specific to i386 and x86-64. > @end deftp > diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c > index b9444dd..c6767d9 100644 > --- a/sysdeps/x86/cacheinfo.c > +++ b/sysdeps/x86/cacheinfo.c > @@ -778,14 +778,16 @@ intel_bug_no_cache_info: > __x86_shared_cache_size = shared; > } > > - /* The large memcpy micro benchmark in glibc shows that 6 times of > - shared cache size is the approximate value above which non-temporal > - store becomes faster on a 8-core processor. This is the 3/4 of the > - total shared cache size. */ > + /* The default setting for the non_temporal threshold is 3/4 > + of one thread's share of the chip's cache. While higher > + single thread performance may be observed with a higher > + threshold, having a single thread use more than it's share > + of the cache will negatively impact the performance of > + other threads running on the chip. */ > __x86_shared_non_temporal_threshold > = (cpu_features->non_temporal_threshold != 0 > ? cpu_features->non_temporal_threshold > - : __x86_shared_cache_size * threads * 3 / 4); > + : __x86_shared_cache_size * 3 / 4); > } > Can we tune it with the number of threads and/or total cache size? -- H.J.