diff mbox series

[urcu] fix: bump tests thread limit to 256

Message ID 20201209181537.444048-1-mjeanson@efficios.com
State New
Headers show
Series [urcu] fix: bump tests thread limit to 256 | expand

Commit Message

Michael Jeanson Dec. 9, 2020, 6:15 p.m. UTC
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(-)

Comments

Mathieu Desnoyers Dec. 9, 2020, 6:29 p.m. UTC | #1
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
Paul E. McKenney Dec. 9, 2020, 7:38 p.m. UTC | #2
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
Mathieu Desnoyers Dec. 11, 2020, 6:31 p.m. UTC | #3
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
diff mbox series

Patch

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)