[COLUG] stress-testing multi-core systems

[James Dinan]

Hi Scott,

> It's been communicated to me that running multiple instances of the
> same application is not as ideal as running a single highly threaded
> application.

>From a management perspective you do have to wrangle several processes
which requires a little extra leg work but you can write a wrapper to do
this for you.  But, from the stress testing perspective, I don't see any
advantage to threads vs. separate processes.  In fact, depending on the
OS and threading library, you might actually get better coverage with
processes than threads because processes are scheduled independently and
threads can be scheduled in lots of different ways that won't map N
threads concurrently onto N cores (M-to-N scheduling under Solaris,
user-space threading, etc).  LinuxThreads (I think may be gone now in
NPTL, not sure) would actually run an extra management thread for each
program using Pthreads to handle things like signal distribution and
synchronization.

> I've also been told -- though have not confirmed for
> myself -- that running multiple instances of F at H particularly can
> cause problems: terminating one instance can cause the other instance
> to foul up in obscure ways.
> 
> Can I restate my original question to seek advice on a single
> executable that will tax all of the available CPU cores in a system?
> Does such a thing exist?

Are you worried about having a true parallel application with
communicating threads or are you just looking for something that is
easier to manage?

In terms of a true parallel benchmark, there are lots but they are
generally not so easy to build and may require some additional libraries
like MPI or the linear algebra libraries (BLAS, LAPACK, etc).  One that
comes to mind is the Linpack benchmark used for the top500 list.
Others include NAS, SPLASH, and HPCC.  However, these are large-scale
benchmarks designed not only to stress the compute power of individual
processors but also interconnect speed and/or shared memory performance.
I don't know of any specific multi-core benchmarks.  If anyone else
does, I'd be very interested to hear about it.

If you don't care about communicating threads and you buy my argument
above, I've attached a small wrapper program that will make running N
instances of a program easier to manage.

Runn will "run n" copies of a program in a new process group.  Because
it creates a new process group, it will live past logging out of an
interactive session if it's run in the background.  You can easily kill
all n copies by killing the process group ID that it prints out (you
kill groups by giving the kill command the PID as a negative number, eg
"kill -9 -2304").  There is also a linux-specific trick in there using
prctl() that sends SIGKILL to children if, for any reason, the
controlling process dies (eg, you killed only the parent or hit CTRL+C).
You would run this like:

$ runn 8 ./burnMMX

You mentioned wanting your stress tests to play nice with other users on
the system.  To do this, run runn through nice (niceness is inherited so
all subprocesses will inherit runn's niceness when they are created).

$ nice runn 8 ./burnMMX

Hope this is helpful.
 ~jim.

PS- My attachment doesn't seem to be agreeing with mailman.  It's posted
here:  http://www.cse.ohio-state.edu/~dinan/software/runn.c