The version check in cyclic test fails if proc isn't mounted or if OS
name isn't Linux (uClinux isn't uncommon). This patch fixes both
issues.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
CPU affinity isn't supported by all uClibc ports right now.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
as of uClibc-20080416 clock_nanosleep is still not implemented.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
When the output of the -v option is piped into another program and if
more data are sent than the other program can eat, data points get
lost. Since high latency values normally occur much less frequently
than average latency values, the connected program will miss many of
the high latency values, and the realtime capability of a given system
may appear much better than it is.
Therefore, the new option -o RED was introduced. This option causes
cyclictest to suppress every subsequent RED number of samples and
replace them with the maximum of the values encountered during that
sampling interval.
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
- Added support for the kernel tracer as of kernel 2.6.24
- Options mostly identical, irrespective of the kernel version
- Added check whether debug fs is mounted and tracing configured
- -v (verbose) option additionally makes tracing more verbose
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
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>