lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OSZPR01MB6328F2713E40CC7D383035A48B489@OSZPR01MB6328.jpnprd01.prod.outlook.com>
Date:   Wed, 31 May 2023 05:33:18 +0000
From:   "Shaopeng Tan (Fujitsu)" <tan.shaopeng@...itsu.com>
To:     'Ilpo Järvinen' 
        <ilpo.jarvinen@...ux.intel.com>,
        "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

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?

Best regards,
Shaopeng TAN

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ