Message ID | 20201209181537.444048-1-mjeanson@efficios.com |
---|---|
State | Superseded, archived |
Headers |
From: mjeanson at efficios.com (Michael Jeanson) Date: Wed, 9 Dec 2020 13:15:37 -0500 Subject: [lttng-dev] [PATCH urcu] fix: bump tests thread limit to 256 Message-ID: <20201209181537.444048-1-mjeanson@efficios.com> |
Series |
[urcu] fix: bump tests thread limit to 256
|
|
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
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
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
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 --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)