summaryrefslogtreecommitdiffstats
path: root/tests/benchmarks/README
diff options
context:
space:
mode:
Diffstat (limited to 'tests/benchmarks/README')
-rw-r--r--tests/benchmarks/README48
1 files changed, 24 insertions, 24 deletions
diff --git a/tests/benchmarks/README b/tests/benchmarks/README
index d437299fee..8d017cd9a7 100644
--- a/tests/benchmarks/README
+++ b/tests/benchmarks/README
@@ -2,7 +2,7 @@ The most reliable way of running benchmarks is to do it in an otherwise idle
system. On a busy system, the results will vary according to the other tasks
demanding attention in the system.
-We have managed to obtain quite reliable results by doing the following on
+We have managed to obtain quite reliable results by doing the following on
Linux (and you need root):
- switching the scheduler to a Real-Time mode
@@ -10,23 +10,23 @@ Linux (and you need root):
- disabling the other thread of the same core
This should work rather well for CPU-intensive tasks. A task that is in Real-
-Time mode will simply not be preempted by the OS. But if you make OS syscalls,
-especially I/O ones, your task will be de-scheduled. Note that this includes
-page faults, so if you can, make sure your benchmark's warmup code paths touch
+Time mode will simply not be preempted by the OS. But if you make OS syscalls,
+especially I/O ones, your task will be de-scheduled. Note that this includes
+page faults, so if you can, make sure your benchmark's warmup code paths touch
most of the data.
-To do this you need a tool called schedtool (package schedtool), from
+To do this you need a tool called schedtool (package schedtool), from
http://freequaos.host.sk/schedtool/
From this point on, we are using CPU0 for all tasks:
-If you have a Hyperthreaded multi-core processor (Core-i5 and Core-i7), you
-have to disable the other thread of the same core as CPU0. To discover which
+If you have a Hyperthreaded multi-core processor (Core-i5 and Core-i7), you
+have to disable the other thread of the same core as CPU0. To discover which
one it is:
$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
-This will print something like 0,4, meaning that CPUs 0 and 4 are sibling
+This will print something like 0,4, meaning that CPUs 0 and 4 are sibling
threads on the same core. So we'll turn CPU 4 off:
(as root)
@@ -34,7 +34,7 @@ threads on the same core. So we'll turn CPU 4 off:
To turn it back on, echo 1 into the same file.
-To run a task on CPU 0 exclusively, using FIFO RT priority 10, you run the
+To run a task on CPU 0 exclusively, using FIFO RT priority 10, you run the
following:
(as root)
@@ -43,38 +43,38 @@ following:
For example:
# schedtool -F -p 10 -a 1 -e ./tst_bench_qstring -tickcounter
-Warning: if your task livelocks or takes far too long to complete, your system
-may be unusable for a long time, especially if you don't have other cores to
+Warning: if your task livelocks or takes far too long to complete, your system
+may be unusable for a long time, especially if you don't have other cores to
run stuff on. To prevent that, run it before schedtool and time it.
-You can also limit the CPU time that the task is allowed to take. Run in the
+You can also limit the CPU time that the task is allowed to take. Run in the
same shell as you'll run schedtool:
$ ulimit -s 300
To limit to 300 seconds (5 minutes)
-If your task runs away, it will get a SIGXCPU after consuming 5 minutes of CPU
+If your task runs away, it will get a SIGXCPU after consuming 5 minutes of CPU
time (5 minutes running at 100%).
-If your app is multithreaded, you may want to give it more CPUs, like CPU0 and
+If your app is multithreaded, you may want to give it more CPUs, like CPU0 and
CPU1 with -a 3 (it's a bitmask).
-For best results, you should disable ALL other cores and threads of the same
-processor. The new Core-i7 have one processor with 4 cores,
-each core can run 2 threads; the older Mac Pros have two processors with 4
-cores each. So on those Mac Pros, you'd disable cores 1, 2 and 3, while on the
+For best results, you should disable ALL other cores and threads of the same
+processor. The new Core-i7 have one processor with 4 cores,
+each core can run 2 threads; the older Mac Pros have two processors with 4
+cores each. So on those Mac Pros, you'd disable cores 1, 2 and 3, while on the
Core-i7, you'll need to disable all other CPUs.
-However, disabling just the sibling thread seems to produce very reliable
-results for me already, with variance often below 0.5% (even though there are
+However, disabling just the sibling thread seems to produce very reliable
+results for me already, with variance often below 0.5% (even though there are
some measurable spikes).
Other things to try:
-Running the benchmark with highest priority, i.e. "sudo nice -19"
-usually produces stable results on some machines. If the benchmark also
-involves displaying something on the screen (on X11), running it with
-"-sync" is a must. Though, in that case the "real" cost is not correct,
+Running the benchmark with highest priority, i.e. "sudo nice -19"
+usually produces stable results on some machines. If the benchmark also
+involves displaying something on the screen (on X11), running it with
+"-sync" is a must. Though, in that case the "real" cost is not correct,
but it is useful to discover regressions.
Also; not many people know about ionice (1)