mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Horgan <ben.horgan@arm.com>
To: Richard Cheng <icheng@nvidia.com>,
	tony.luck@intel.com, reinette.chatre@intel.com, x86@kernel.org,
	shuah@kernel.org, fenghuay@nvidia.com
Cc: Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	kaihengf@nvidia.com, kobak@nvidia.com, newtonl@nvidia.com,
	kristinc@nvidia.com
Subject: Re: [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64
Date: Tue, 20 Oct 2026 17:30:33 +0100	[thread overview]
Message-ID: <847af89d-7b79-44b4-8273-243dfb51ef5e@arm.com> (raw)
In-Reply-To: <20261012074729.40042-2-icheng@nvidia.com>

Hi Richard,

Thanks for having a look at the arm64 side of the resctrl selftests. That hasn't had much love but
it would be good to have them working properly.

On 12/10/2026 08:47, Richard Cheng wrote:
> cl_flush() and sb() compile to empty functions on aarch64, making
> mem_flush() a silent no-op and leaving CMT/CAT tests operating on
> unflushed state.
> 
> Add "dsb sy" for sb(), ARM requires a DSB whose access type covers both
> loads and stores.

I guess this is referring to the synchronization required for the cache maintenance instruction but
that's not what you are using in this patch.

> 
> For cl_flush(), "dc civac" only reaches the Point of Coherency, on
> ARM MPAM systems the SLC lies past the PoC and may be a NOP on coherent
> platforms. Instead, dirty each cacheline with a store so that
> mem_flush's full-buffer sweep evicts lines from the SLC via LRU
> pressure.
> 
> Signed-off-by: Richard Cheng <icheng@nvidia.com>
> ---
>  tools/testing/selftests/resctrl/fill_buf.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/testing/selftests/resctrl/fill_buf.c b/tools/testing/selftests/resctrl/fill_buf.c
> index b9fa7968cd6e..eae0262fe265 100644
> --- a/tools/testing/selftests/resctrl/fill_buf.c
> +++ b/tools/testing/selftests/resctrl/fill_buf.c
> @@ -27,6 +27,9 @@ static void sb(void)
>  #if defined(__i386) || defined(__x86_64)
>  	asm volatile("sfence\n\t"
>  		     : : : "memory");
> +#elif defined(__aarch64__)
> +	asm volatile("dsb sy\n\t"
> +		     : : : "memory");
>  #endif
>  }
>  
> @@ -35,6 +38,14 @@ static void cl_flush(void *p)
>  #if defined(__i386) || defined(__x86_64)
>  	asm volatile("clflush (%0)\n\t"
>  		     : : "r"(p) : "memory");
> +#elif defined(__aarch64__)
> +	/*
> +	 * Dirty the cache line with a store. As mem_flush() sweeps
> +	 * the full test buffer (sized larger than the SLC), cache pressure
> +	 * evicts lines from the SLC via LRU replacement.
> +	 */
> +	asm volatile("strb wzr, [%0]\n\t"
> +		     : : "r"(p) : "memory");
>  #endif

Isn't this cl_flush() used without changing the resctrl control and monitor group (PARTID/PMG)?
Hence, I expect you are ending up making the cache full of data associated with the identifiers that
the benchmark runs with. Is that the case?

I'm also unclear how this the cat_test will detect any performance differences on arm/MPAM as the
perf events would need to specific to the system level cache implementation.

Thanks,

Ben



>  }
>  


  reply	other threads:[~2026-10-20 16:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12  7:47 [PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64 Richard Cheng
2026-10-12  7:47 ` [PATCH v5 1/2] selftests/resctrl: Implement cl_flush() and sb() for aarch64 Richard Cheng
2026-10-20 16:30   ` Ben Horgan [this message]
2026-10-12  7:47 ` [PATCH v5 2/2] selftests/resctrl: Recognise aarch64 as a vendor for L3_NONCONT_CAT Richard Cheng
2026-10-20 16:18   ` Ben Horgan
2026-10-12 22:09 ` [PATCH v5 0/2] selftests/resctrl: Fix resctrl selftests issues on aarch64 Reinette Chatre

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=847af89d-7b79-44b4-8273-243dfb51ef5e@arm.com \
    --to=ben.horgan@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=fenghuay@nvidia.com \
    --cc=icheng@nvidia.com \
    --cc=james.morse@arm.com \
    --cc=kaihengf@nvidia.com \
    --cc=kobak@nvidia.com \
    --cc=kristinc@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=newtonl@nvidia.com \
    --cc=reinette.chatre@intel.com \
    --cc=shuah@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®