From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by sourceware.org (Postfix) with ESMTPS id 36CB13857C45 for ; Wed, 23 Sep 2020 17:19:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 36CB13857C45 Received: by mail-il1-x143.google.com with SMTP id t18so362690ilp.5 for ; Wed, 23 Sep 2020 10:19:43 -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=G/RAAosss1PLPh1FBPxBi4abw8BgCMrlRZNNjUbf/ZQ=; b=NM6wVhG536kJmB2X9AVYTjfzYO4S9S900cHGvvruRCo4UWFhG70mSJXGsicUaXrqr3 CBvCqTFP4MTXqU5YE+SoFC5MM76lx8W5diRpxZlFJvibq/zFdOZOJx+zYaSdDzDuVYe9 cDuySLVERpkjXCXDMcFTvORlrnawtbi+U0c01Htfhe0L0VOSim04dkUQuC0Adkjsknlh T1aiZpAcuo+8s1Cr8+McwWZixa/sj51cy6+wcyKObPg0gEWB1zEwF2X+vV6SnF/Ko91f WHbYmVL94JpJzfpLJKvZHWVYNsjLmiinA2LALVGfxh5G8Y0NzHD9m2n3Uend/J67EVH3 /0IQ== X-Gm-Message-State: AOAM5325sJsB+ahdWbLqbTMpL5wV2Miu47W9W8gdFkhBwHd3XlaFZner a7AE1UZZZ60Nxvm4hTq5pcTsT+cwNXsMHjIAqVQ= X-Google-Smtp-Source: ABdhPJzWOFPHENf8yhM1xLrcyf8Or8az6yftHW3gRyJhkZRhMAcyYj9kZjYl74Od937/K2GXWEZLd6pP9pS/q55Aln4= X-Received: by 2002:a92:6a09:: with SMTP id f9mr683822ilc.273.1600881582727; Wed, 23 Sep 2020 10:19:42 -0700 (PDT) MIME-Version: 1.0 References: <1600874027-7718-1-git-send-email-patrick.mcgehearty@oracle.com> In-Reply-To: <1600874027-7718-1-git-send-email-patrick.mcgehearty@oracle.com> From: "H.J. Lu" Date: Wed, 23 Sep 2020 10:19:06 -0700 Message-ID: Subject: Re: [PATCH] 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=-8.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 17:19:44 -0000 On Wed, Sep 23, 2020 at 8:14 AM 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 | 2 +- > 2 files changed, 6 insertions(+), 2 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..5c5192a 100644 > --- a/sysdeps/x86/cacheinfo.c > +++ b/sysdeps/x86/cacheinfo.c > @@ -785,7 +785,7 @@ intel_bug_no_cache_info: > __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); > } > You need to update the comment for __x86_shared_non_temporal_threshold. -- H.J.