forked from Minki/linux
5395467103
Running the standard set of rcutorture tests on 24 CPUs results in the following sub-optimal schedule: ----start batch---- TREE07 16 ----start batch---- TREE08 16 SRCU-P 8 ----start batch---- TREE01 8 TREE02 8 TREE03 8 ----start batch---- TREE04 8 TREE05 8 TREE06 8 ----start batch---- SRCU-N 4 TINY01 1 TINY02 1 TREE09 1 If one of the eight-CPU runs were to be moved into the first batch, the test suite would complete in four batches rather than five. This commit therefore uses a greedy algorithm to re-order the test entries so that the sequential batching will produce an optimal schedule in this case: ----start batch---- TREE07 16 SRCU-P 8 ----start batch---- TREE08 16 TREE01 8 ----start batch---- TREE02 8 TREE03 8 TREE04 8 ----start batch---- TREE05 8 TREE06 8 SRCU-N 4 TINY01 1 TINY02 1 TREE09 1 Please note that this is still not an optimal bin-packing algorithm, however, it does produce optimal solutions for most common scenarios. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> |
||
---|---|---|
.. | ||
breakpoints | ||
cpu-hotplug | ||
efivarfs | ||
ipc | ||
kcmp | ||
memory-hotplug | ||
mqueue | ||
net | ||
powerpc | ||
ptrace | ||
rcutorture | ||
timers | ||
user | ||
vm | ||
Makefile | ||
README.txt |
Linux Kernel Selftests The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel. Running the selftests ===================== To build the tests: $ make -C tools/testing/selftests To run the tests: $ make -C tools/testing/selftests run_tests - note that some tests will require root privileges. To run only tests targetted for a single subsystem: $ make -C tools/testing/selftests TARGETS=cpu-hotplug run_tests See the top-level tools/testing/selftests/Makefile for the list of all possible targets. Contributing new tests ====================== In general, the rules for for selftests are * Do as much as you can if you're not root; * Don't take too long; * Don't break the build on any architecture, and * Don't cause the top-level "make run_tests" to fail if your feature is unconfigured.