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

[Mathieu Desnoyers]

Hi Michael,

After discussion with Paul, we can go for bumping the max nr cpu limit
of this test to 4096.

1536 would cover all the current hardware Paul E. McKenney is aware of.
4096 would cover all hardware he has ever received a bug report on.

Can you try it out and submit an updated patch ?

Thanks,

Mathieu

----- On Dec 9, 2020, at 1:29 PM, Mathieu Desnoyers mathieu.desnoyers at efficios.com 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 ?
> 
> 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

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com