Hi Ilpo,

On 8/30/24 4:25 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:

By default the MBM and MBA tests use the "fill_buf" benchmark to
read from a buffer with the goal to measure the memory bandwidth
generated by this buffer access.

Care should be taken when sizing the buffer used by the "fill_buf"
benchmark. If the buffer is small enough to fit in the cache then
it cannot be expected that the benchmark will generate much memory
bandwidth. For example, on a system with 320MB L3 cache the existing
hardcoded default of 250MB is insufficient.

Use the measured cache size to determine a buffer size that can be
expected to trigger memory access while keeping the existing default
as minimum that has been appropriate for testing so far.

Signed-off-by: Reinette Chatre <reinette.cha...@intel.com>
---
  tools/testing/selftests/resctrl/mba_test.c | 8 +++++++-
  tools/testing/selftests/resctrl/mbm_test.c | 8 +++++++-
  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/resctrl/mba_test.c 
b/tools/testing/selftests/resctrl/mba_test.c
index 8ad433495f61..cad473b81a64 100644
--- a/tools/testing/selftests/resctrl/mba_test.c
+++ b/tools/testing/selftests/resctrl/mba_test.c
@@ -170,11 +170,17 @@ static int mba_run_test(const struct resctrl_test *test, 
const struct user_param
                .setup          = mba_setup,
                .measure        = mba_measure,
        };
+       unsigned long cache_total_size = 0;
        int ret;
remove(RESULT_FILE_NAME); - param.fill_buf.buf_size = DEFAULT_SPAN;
+       ret = get_cache_size(uparams->cpu, "L3", &cache_total_size);
+       if (ret)
+               return ret;
+
+       param.fill_buf.buf_size = cache_total_size > DEFAULT_SPAN ?
+                                 cache_total_size * 2 : DEFAULT_SPAN;

Should the check leave a bit of safeguard so that the buf_size is at
least 2x (or x1.25 or some other factor)?

In here buf_size immediate jumps from 1x -> 2x when cache_total_size goes
from DEFAULT_SPAN to DEFAULT_SPAN+1 (obviously L3 size won't be odd like
that but I think you get my point).

Good catch. Will fix.


Also, user might want to override this as mentioned in my reply to the
previous patch.


ack.

Reinette

Reply via email to