[lttng-dev] [PATCH urcu] fix: bump tests thread limit to 256

[Paul E. McKenney]

On Wed, Dec 09, 2020 at 01:29:47PM -0500, Mathieu Desnoyers wrote:
> Hi Paul,
> 
> Should I merge this temporary fix for liburcu tests, or should we go
> for dynamic allocation of the array right away instead ?

Getting something running now is a good thing.  I have occasional access
to a system that could use 512, though.  (448 suffices, but powers of
two and all that.)

Longer term, I agree with dynamic allocation.

							Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> ----- On Dec 9, 2020, at 1:15 PM, Michael Jeanson mjeanson at efficios.com wrote:
> 
> > Machines with more than 128 CPUs are becomming more common, the proper
> > fix here would be to dynamically allocate the array which we will do,
> > but in the meantime bump the limit to 256 to fix the problem on a 160
> > CPUs ppc64el system where this was reported.
> > 
> > Signed-off-by: Michael Jeanson <mjeanson at efficios.com>
> > Cc: Paul E. McKenney <paulmck at kernel.org>
> > Change-Id: Ib3cb5d8cb4515e6f626be33c2685fa38cb081782
> > ---
> > tests/common/api.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tests/common/api.h b/tests/common/api.h
> > index 2b72ec5..b15e588 100644
> > --- a/tests/common/api.h
> > +++ b/tests/common/api.h
> > @@ -108,7 +108,7 @@ static void spin_unlock(spinlock_t *sp)
> > 
> > typedef pthread_t thread_id_t;
> > 
> > -#define NR_THREADS 128
> > +#define NR_THREADS 256
> > 
> > #define __THREAD_ID_MAP_EMPTY ((thread_id_t) 0)
> > #define __THREAD_ID_MAP_WAITING ((thread_id_t) 1)
> > --
> > 2.29.2
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com