[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c21fb16d-d3ad-bbcb-daed-28f153b64525@linux.intel.com>
Date: Wed, 31 May 2023 12:17:23 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: "Shaopeng Tan (Fujitsu)" <tan.shaopeng@...itsu.com>
cc: "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
Reinette Chatre <reinette.chatre@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Shuah Khan <shuah@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 21/24] selftests/resctrl: Read in less obvious order
to defeat prefetch optimizations
On Wed, 31 May 2023, Shaopeng Tan (Fujitsu) wrote:
> Hi Ilpo,
>
> > When reading memory in order, HW prefetching optimizations will interfere
> > with measuring how caches and memory are being accessed. This adds noise
> > into the results.
> >
> > Change the fill_buf reading loop to not use an obvious in-order access using
> > multiply by a prime and modulo.
> >
> > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> > ---
> > tools/testing/selftests/resctrl/fill_buf.c | 17 ++++++++++-------
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/testing/selftests/resctrl/fill_buf.c
> > b/tools/testing/selftests/resctrl/fill_buf.c
> > index 7e0d3a1ea555..049a520498a9 100644
> > --- a/tools/testing/selftests/resctrl/fill_buf.c
> > +++ b/tools/testing/selftests/resctrl/fill_buf.c
> > @@ -88,14 +88,17 @@ static void *malloc_and_init_memory(size_t s)
> >
> > static int fill_one_span_read(unsigned char *start_ptr, unsigned char
> > *end_ptr) {
> > - unsigned char sum, *p;
> > -
> > + unsigned int size = (end_ptr - start_ptr) / (CL_SIZE / 2);
> > + unsigned int count = size;
> > + unsigned char sum;
> > +
> > + /*
> > + * Read the buffer in an order that is unexpected by HW prefetching
> > + * optimizations to prevent them interfering with the caching pattern.
> > + */
> > sum = 0;
> > - p = start_ptr;
> > - while (p < end_ptr) {
> > - sum += *p;
> > - p += (CL_SIZE / 2);
> > - }
> > + while (count--)
> > + sum += start_ptr[((count * 59) % size) * CL_SIZE / 2];
>
> Could you please elaborate why 59 is used?
The main reason is that it's a prime number ensuring the whole buffer
gets read. I picked something that doesn't make it to wrap on almost
every iteration.
--
i.
Powered by blists - more mailing lists