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@linux.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.*/
- 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.