public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Noah Goldstein <goldstein.w.n@gmail.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] x86: Check the minimum non_temporal_threshold [BZ #29953]
Date: Tue, 3 Jan 2023 12:49:46 -0800	[thread overview]
Message-ID: <CAMe9rOrBsq-sGL0-xKqn3uog93DD5YXjbi7Gqk4WqCgwN+gCGg@mail.gmail.com> (raw)
In-Reply-To: <CAFUsyf+y=rvVd=mduVz9s_o-0QfqbDBb7-zS-dFTQSVEUdgypA@mail.gmail.com>

On Tue, Jan 3, 2023 at 12:24 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> On Tue, Jan 3, 2023 at 11:37 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > The minimum non_temporal_threshold is 0x4040.  non_temporal_threshold may
> > be set to less than the minimum value when the shared cache size isn't
> > available (e.g., in an emulator) or by the tunable.  Add a check for
> > the minimum non_temporal_threshold.
> >
> > This fixes BZ #29953.
> > ---
> >  sysdeps/x86/dl-cacheinfo.h | 23 ++++++++++++++---------
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/sysdeps/x86/dl-cacheinfo.h b/sysdeps/x86/dl-cacheinfo.h
> > index e9f3382108..92e8e40752 100644
> > --- a/sysdeps/x86/dl-cacheinfo.h
> > +++ b/sysdeps/x86/dl-cacheinfo.h
> > @@ -861,8 +861,18 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
> >       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 = shared * 3 / 4;
> > +  /* SIZE_MAX >> 4 because memmove-vec-unaligned-erms right-shifts the value of
> > +     'x86_non_temporal_threshold' by `LOG_4X_MEMCPY_THRESH` (4) and it is best
> > +     if that operation cannot overflow. Minimum of 0x4040 (16448) because the
> > +     L(large_memset_4x) loops need 64-byte to cache align and enough space for
> > +     at least 1 iteration of 4x PAGE_SIZE unrolled loop.  Both values are
> > +     reflected in the manual.  */
> > +  unsigned long int minimum_non_temporal_threshold = 0x4040;
> > +  if (non_temporal_threshold < minimum_non_temporal_threshold)
> > +    non_temporal_threshold = minimum_non_temporal_threshold;
> >
> Should we have equivalent logic for max incase shared is somehow >
> SIZE_MAX / 12?

Good point.   Will be updated in v2.

> >  #if HAVE_TUNABLES
> > +  unsigned long int maximum_non_temporal_threshold = SIZE_MAX >> 4;
> >    /* NB: The REP MOVSB threshold must be greater than VEC_SIZE * 8.  */
> >    unsigned int minimum_rep_movsb_threshold;
> >  #endif
> > @@ -915,8 +925,8 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
> >      shared = tunable_size;
> >
> >    tunable_size = TUNABLE_GET (x86_non_temporal_threshold, long int, NULL);
> > -  /* NB: Ignore the default value 0.  */
> > -  if (tunable_size != 0)
> > +  if (tunable_size > minimum_non_temporal_threshold
> > +      && tunable_size <= maximum_non_temporal_threshold)
> >      non_temporal_threshold = tunable_size;
> >
> >    tunable_size = TUNABLE_GET (x86_rep_movsb_threshold, long int, NULL);
> > @@ -931,14 +941,9 @@ dl_init_cacheinfo (struct cpu_features *cpu_features)
> >
> >    TUNABLE_SET_WITH_BOUNDS (x86_data_cache_size, data, 0, SIZE_MAX);
> >    TUNABLE_SET_WITH_BOUNDS (x86_shared_cache_size, shared, 0, SIZE_MAX);
> > -  /* SIZE_MAX >> 4 because memmove-vec-unaligned-erms right-shifts the value of
> > -     'x86_non_temporal_threshold' by `LOG_4X_MEMCPY_THRESH` (4) and it is best
> > -     if that operation cannot overflow. Minimum of 0x4040 (16448) because the
> > -     L(large_memset_4x) loops need 64-byte to cache align and enough space for
> > -     at least 1 iteration of 4x PAGE_SIZE unrolled loop.  Both values are
> > -     reflected in the manual.  */
> >    TUNABLE_SET_WITH_BOUNDS (x86_non_temporal_threshold, non_temporal_threshold,
> > -                          0x4040, SIZE_MAX >> 4);
> > +                          minimum_non_temporal_threshold,
> > +                          maximum_non_temporal_threshold);
> >    TUNABLE_SET_WITH_BOUNDS (x86_rep_movsb_threshold, rep_movsb_threshold,
> >                            minimum_rep_movsb_threshold, SIZE_MAX);
> >    TUNABLE_SET_WITH_BOUNDS (x86_rep_stosb_threshold, rep_stosb_threshold, 1,
> > --
> > 2.39.0
> >



-- 
H.J.

      reply	other threads:[~2023-01-03 20:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-03 19:37 H.J. Lu
2023-01-03 20:24 ` Noah Goldstein
2023-01-03 20:49   ` H.J. Lu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOrBsq-sGL0-xKqn3uog93DD5YXjbi7Gqk4WqCgwN+gCGg@mail.gmail.com \
    --to=hjl.tools@gmail.com \
    --cc=goldstein.w.n@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).