[PATCH v3 03/14] test/mcslock: scale test based on number of cores

[Stephen Hemminger]

On Thu, 22 Jan 2026 10:41:04 +0000
Konstantin Ananyev <konstantin.ananyev at huawei.com> wrote:

> > This test uses loops to synchronize but has problems on systems
> > with high number of cores. Scale iterations to the number of
> > cores.
> > 
> > Fixes: 32dcb9fd2a22 ("test/mcslock: add MCS queued lock unit test")
> > Cc: stable at dpdk.org
> > 
> > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> > ---
> >  app/test/test_mcslock.c | 10 +++++++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/app/test/test_mcslock.c b/app/test/test_mcslock.c
> > index 245df99a5d..b182da72f1 100644
> > --- a/app/test/test_mcslock.c
> > +++ b/app/test/test_mcslock.c
> > @@ -42,6 +42,10 @@ RTE_ATOMIC(rte_mcslock_t *) p_ml_perf;
> > 
> >  static unsigned int count;
> > 
> > +#define MAX_LOOP_BASE  1000000u
> > +#define MAX_LOOP_MIN   10000u
> > +static unsigned int max_loop;
> > +
> >  static RTE_ATOMIC(uint32_t) synchro;
> > 
> >  static int
> > @@ -60,8 +64,6 @@ test_mcslock_per_core(__rte_unused void *arg)
> > 
> >  static uint64_t time_count[RTE_MAX_LCORE] = {0};
> > 
> > -#define MAX_LOOP 1000000
> > -
> >  static int
> >  load_loop_fn(void *func_param)
> >  {
> > @@ -78,7 +80,7 @@ load_loop_fn(void *func_param)
> >  	rte_wait_until_equal_32((uint32_t *)(uintptr_t)&synchro, 1,
> > rte_memory_order_relaxed);
> > 
> >  	begin = rte_get_timer_cycles();
> > -	while (lcount < MAX_LOOP) {
> > +	while (lcount < max_loop) {
> >  		if (use_lock)
> >  			rte_mcslock_lock(&p_ml_perf, &ml_perf_me);
> > 
> > @@ -175,6 +177,8 @@ test_mcslock(void)
> >  	rte_mcslock_t ml_me;
> >  	rte_mcslock_t ml_try_me;
> > 
> > +	max_loop = test_scale_iterations(MAX_LOOP_BASE, MAX_LOOP_MIN);
> > +  
> 
> Here, and in other similar cases, would it make sense to terminate by timeout
> (i.e. number of cycles passed since start of the test)?
>  

Thought about that but there are couple of issues:
 1. The act of reading the TSC value would change CPU behavior and reduce
    the amount of contention. Potentially hiding bugs.
 2. If the test suddenly had much worse performance, the number of iterations
    would be much less but if test was based on timeout it wouldn't see it.

Conclusion: keep original iteration based limits