Add CPU affinitt option to cyclictest.
1. New option -a:
without argument to a cyclictest spreads the threads consecutive on
the available CPUs. On a quad core machine we get:
-a -t4 Thread #0 -> CPU #0
Thread #1 -> CPU #1
Thread #2 -> CPU #2
Thread #3 -> CPU #3
-a -t5 Thread #0 -> CPU #0
Thread #1 -> CPU #1
Thread #2 -> CPU #2
Thread #3 -> CPU #3
Thread #4 -> CPU #0
Adding a CPU number to the -a option all threads are pinned to
the given CPU:
-a3 -t4 Thread #0 -> CPU #3
Thread #1 -> CPU #3
Thread #2 -> CPU #3
Thread #3 -> CPU #3
2. extension of the -t option:
Without argument to -t cyclictest starts as many threads as CPUs are
available.
Signed-off-by: Carsten Emde <c.emde@osadl.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This is a patch that's a ripple from the bug in signaltest that Luis and Jeff Burke
were working on. Looks like there's a race where a variable can be used
uninitialized, depending on thread scheduling circumstances. Probably not major, but
hey, can't hurt :).
Signed-off-by: Clark Williams <williams@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signaltest was hanging in a wide variety of kernel versions, in some cases
after a few iterations and in other cases right after being called on the
command line. We created a bugzilla ticket for this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=308231
After a few debug sessions we realized that a shared variable used to
synchronize the work between threads, stat[i].threadstarted, could end up
being used before initialization depending on the scheduling of the
threads.
The fix is a one-liner.
Signed-off-by: Luis Claudio R. Goncalves <lclaudio@uudg.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>