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 mjean...@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 <mjean...@efficios.com> > > Cc: Paul E. McKenney <paul...@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 _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev