| Message ID | 20170830124448.87C7741BE92E8@oldenburg.str.redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Do not scale NPTL tests with available number of CPUs | expand |
On 30/08/2017 09:44, Florian Weimer wrote: > On very large multi-processor systems, creating hundreds of threads > runs into a test time out. The tests do not seem to benefit from > massive over-scheduling. > > 2017-08-30 Florian Weimer <fweimer@redhat.com> > > Do not scale NPTL tests with available number of CPUs. > * nptl/tst-cond16.c (count): Sett to constant value of 8. > * nptl/tst-cond18.c (count): Likewise. LGTM. > > diff --git a/nptl/tst-cond16.c b/nptl/tst-cond16.c > index 032677adcc..b3bfb90bd4 100644 > --- a/nptl/tst-cond16.c > +++ b/nptl/tst-cond16.c > @@ -28,7 +28,7 @@ pthread_cond_t cv = PTHREAD_COND_INITIALIZER; > pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > bool n, exiting; > FILE *f; > -int count; > +enum { count = 8 }; /* Number of worker threads. */ > > void * > tf (void *dummy) > @@ -71,11 +71,6 @@ do_test (void) > return 1; > } > > - count = sysconf (_SC_NPROCESSORS_ONLN); > - if (count <= 0) > - count = 1; > - count *= 4; > - > pthread_t th[count]; > pthread_attr_t attr; > int i, ret, sz; > diff --git a/nptl/tst-cond18.c b/nptl/tst-cond18.c > index 187f3af1df..6276110ec2 100644 > --- a/nptl/tst-cond18.c > +++ b/nptl/tst-cond18.c > @@ -28,7 +28,8 @@ > pthread_cond_t cv = PTHREAD_COND_INITIALIZER; > pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; > bool exiting; > -int fd, count, spins, nn; > +int fd, spins, nn; > +enum { count = 8 }; /* Number of worker threads. */ > > void * > tf (void *id) > @@ -82,11 +83,6 @@ do_test (void) > return 1; > } > > - count = sysconf (_SC_NPROCESSORS_ONLN); > - if (count <= 0) > - count = 1; > - count *= 8; > - > pthread_t th[count + 1]; > pthread_attr_t attr; > int i, ret, sz; >
On Wed, Aug 30, 2017 at 10:08 AM, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote: > On 30/08/2017 09:44, Florian Weimer wrote: >> On very large multi-processor systems, creating hundreds of threads >> runs into a test time out. The tests do not seem to benefit from >> massive over-scheduling. >> >> 2017-08-30 Florian Weimer <fweimer@redhat.com> >> >> Do not scale NPTL tests with available number of CPUs. >> * nptl/tst-cond16.c (count): Sett to constant value of 8. This verb is spelled "set" in English, not "sett". Should it maybe be min(8, ncpus) instead of just 8? zw
On 08/30/2017 04:21 PM, Zack Weinberg wrote: > On Wed, Aug 30, 2017 at 10:08 AM, Adhemerval Zanella > <adhemerval.zanella@linaro.org> wrote: >> On 30/08/2017 09:44, Florian Weimer wrote: >>> On very large multi-processor systems, creating hundreds of threads >>> runs into a test time out. The tests do not seem to benefit from >>> massive over-scheduling. >>> >>> 2017-08-30 Florian Weimer <fweimer@redhat.com> >>> >>> Do not scale NPTL tests with available number of CPUs. >>> * nptl/tst-cond16.c (count): Sett to constant value of 8. > > This verb is spelled "set" in English, not "sett". I fixed that before committing. > Should it maybe be min(8, ncpus) instead of just 8? I don't think that's worth the added complexity. Even on a UP system, the overscheduling does not introduce a significant delay in thread creation and termination. $ time taskset 1 bash testrun.sh nptl/tst-cond16 real 0m20.005s user 0m19.984s sys 0m0.020s Thanks, Florian
On Wed, Aug 30, 2017 at 10:32 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 08/30/2017 04:21 PM, Zack Weinberg wrote: >> Should it maybe be min(8, ncpus) instead of just 8? > > I don't think that's worth the added complexity. Even on a UP system, > the overscheduling does not introduce a significant delay in thread > creation and termination. OK, thanks for clarifying. zw
On 08/30/2017 07:44 AM, Florian Weimer wrote: > On very large multi-processor systems, creating hundreds of threads > runs into a test time out. The tests do not seem to benefit from > massive over-scheduling. > > 2017-08-30 Florian Weimer <fweimer@redhat.com> > > Do not scale NPTL tests with available number of CPUs. > * nptl/tst-cond16.c (count): Sett to constant value of 8. > * nptl/tst-cond18.c (count): Likewise. The patch looks good to me. What I would *like* to see here is a support override for this. An API which passes in a default, 8 cpus, and the output is 8 cpus, so long as the support library doesn't override the number of cpus to use. This way I can re-run the entire testsuite with maximum number of cpus for tests that claim such scalability.
diff --git a/nptl/tst-cond16.c b/nptl/tst-cond16.c index 032677adcc..b3bfb90bd4 100644 --- a/nptl/tst-cond16.c +++ b/nptl/tst-cond16.c @@ -28,7 +28,7 @@ pthread_cond_t cv = PTHREAD_COND_INITIALIZER; pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; bool n, exiting; FILE *f; -int count; +enum { count = 8 }; /* Number of worker threads. */ void * tf (void *dummy) @@ -71,11 +71,6 @@ do_test (void) return 1; } - count = sysconf (_SC_NPROCESSORS_ONLN); - if (count <= 0) - count = 1; - count *= 4; - pthread_t th[count]; pthread_attr_t attr; int i, ret, sz; diff --git a/nptl/tst-cond18.c b/nptl/tst-cond18.c index 187f3af1df..6276110ec2 100644 --- a/nptl/tst-cond18.c +++ b/nptl/tst-cond18.c @@ -28,7 +28,8 @@ pthread_cond_t cv = PTHREAD_COND_INITIALIZER; pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; bool exiting; -int fd, count, spins, nn; +int fd, spins, nn; +enum { count = 8 }; /* Number of worker threads. */ void * tf (void *id) @@ -82,11 +83,6 @@ do_test (void) return 1; } - count = sysconf (_SC_NPROCESSORS_ONLN); - if (count <= 0) - count = 1; - count *= 8; - pthread_t th[count + 1]; pthread_attr_t attr; int i, ret, sz;