From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by sourceware.org (Postfix) with ESMTPS id F3CB73851C2C for ; Fri, 25 Sep 2020 22:26:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F3CB73851C2C Received: by mail-il1-x141.google.com with SMTP id y2so3864302ila.0 for ; Fri, 25 Sep 2020 15:26:45 -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=QvUBWyuSawg+UbQ6QlFSyYa3A44weGtAoPPMg7phOGs=; b=Tia0bRnoJtvERMGz4Yrc5a1g88W1ofKHSVntXVOQOW6QsaLkCVdh6pyBXrOYTALH81 T4h4+1p7wm4KkEHWL3ajIiGpPSoqqeqAYI7GyMowJYo19N89nhVpLwwBTb85ycchOe8h 0p6jRURbyAyhA9R7kuECndgNxpcy5cN/X5ZGQnxU40U/Go8mnvddeJmxF6jp5AOkFz++ 9NCh88cp03x3jGya/TTOGk/1RwG1jbMI8R8fUgMzOy3ysoW82huhJamBJGBTAMpIEd+8 7zRE7BDSmRH8VOXiZi+LUHkEOlWOdkvDe88JtVuu9T1RIzuU3lyaSZ5hwDTUBnfRVPmJ eLFw== X-Gm-Message-State: AOAM530Z0w85rvvrh7nxmnpNCGrGxHgWkdcw+Wr+cIawUjOt8eREAzjG kx8N+VmL7SoJWTLGVsJVF/abtT6Uql4YrIqhxEM= X-Google-Smtp-Source: ABdhPJz/FxIaDCJj+uX90fm4K+ElfQFOKSDDR+h5iHH8IFZ3Ion2cF0EpKiujVEE8gwtEIkxoCmvTZ5bU2AXaNN3PFs= X-Received: by 2002:a92:790b:: with SMTP id u11mr2138961ilc.13.1601072805321; Fri, 25 Sep 2020 15:26:45 -0700 (PDT) MIME-Version: 1.0 References: <1601072475-22682-1-git-send-email-patrick.mcgehearty@oracle.com> In-Reply-To: <1601072475-22682-1-git-send-email-patrick.mcgehearty@oracle.com> From: "H.J. Lu" Date: Fri, 25 Sep 2020 15:26:09 -0700 Message-ID: Subject: Re: [PATCH v3] 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=-3036.7 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: Fri, 25 Sep 2020 22:27:04 -0000 On Fri, Sep 25, 2020 at 3: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. > > modified: sysdeps/x86/cacheinfo.c > modified: manual/tunables.texi > --- > manual/tunables.texi | 6 +++++- > sysdeps/x86/cacheinfo.c | 16 +++++++++++----- > 2 files changed, 16 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..42b468d 100644 > --- a/sysdeps/x86/cacheinfo.c > +++ b/sysdeps/x86/cacheinfo.c > @@ -778,14 +778,20 @@ 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. For most Intel and AMD processors > + with an initial release date between 2017 and 2020, a thread's typical > + 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. */ > __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); > } > > #endif LGTM. Thanks. -- H.J.