[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

condvar wakeups



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As already mentioned, we have a patch to change the wakeup in the
condvar code.  To cut the story short, the results I see are mixed.  And
what is more, the measurements I've seen wrt to LinuxThreads don't
support the reports.

First, let me start by saying a word about the paramwu.c program which
has been posted.  It is completely bogus as a benchmark.  It is
completely legitimate that the main thread which executed the loop in
do_test() never sleeps.  There is no reason for it to be forcefully
descheduled if it can keep the mutex locked.  Then the threads whose
execution are actually counted are stalled.  So, I do not take any of
the output serious.  Yes, LT might have much better numbers but only
because it is inefficient.

As for the pingpong program, it is much better suited as a benchmark.
I've written a little bit of code myself, which should show the effects
even more easily.  See below.

We (well, mostly Ingo I guess) will look at the data.  In case somebody
wants to join in the fun, I've uploaded the necessary files:

  http://people.redhat.com/drepper/futex-requeue-2.5.68-U1

    the patch against the current BK kernel

    I have  apatch for a 2.4 kernel but it is worthless for anybody else
    since it for our internal kernels.  It's not hard to port the
    requeue change (not the noresched part) to 2.4.

  http://people.redhat.com/drepper/nptl-requeue.patch.bz2

    Patch on top of nptl-0.37.tar.bz2 to add requeue support for x86
    and ia64.  The bk kernel currently doesn't compile for hammer, so
    I haven't tested it.

  http://people.redhat.com/drepper/cond-perf.c

    My test program.  Note: it is not under GPL or LGPL, you cannot
    redistribute it.


Some numbers.  Use my test program I see the following times on a 4p
ia64 Madison machine.  For 100 concurrent threads

  cond-perf -r 1000 -n 100

             LT                old NPTL          requeue NPTL

minimum:     0.617428174 sec   0.270278439 sec   0.321956284 sec
maximum:     0.621202585 sec   0.305812929 sec   0.327252124 sec
average:     0.619208118 sec   0.290176436 sec   0.324108123 sec

Adding the -k parameter hardly changes the numbers.  On a UP P4 HT
machine I get for the same configuration:

             LT                old NPTL          requeue NPTL

minimum:     1.129867247 sec   0.303806986 sec   0.359285587 sec
maximum:     1.353488790 sec   0.312475095 sec   0.366070266 sec
average:     1.229651937 sec   0.306981890 sec   0.361971481 sec


Needless to say I wasn't expecting the slowdown.  But it is also
noteworthy that even with 100 threads the LT code never comes even close
to the performance of NPTL.  This validates what I wrote before, the
paramwu.c program is really useless as a benchmark.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+s3tm2ijCOnn/RHQRArJjAJ9Xg8Id8U/9dWum0+wG+Fh1RBpAFACfbIxS
i4UT/hhoqM9kCSfY5zi9UCs=
=/8mk
-----END PGP SIGNATURE-----





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]