Quoting original author of this patch as taken from his original from googlecode.com, now issue #4 in Github.
Simply un-limits the 'misc' and 'system' suites.
Half-related thoughts about testing quality:
I'm curious why there's a shell1, shell8, and shell16 set of tests. Aren't the
latter two equivalent to './Run -c 8 shell1' and './Run -c 16 shell1'? I think
shell8 and shell16 are pointless if this is the case.
At the very least, I think shell8 should be out of the default run (the $index
set), because it will essentially give a misleading number if you have more
than a single core in the system. Isn't the purpose of the serial run to
essentially measure how well the system performs on single-threaded activities?
Or perhaps to measure how well a single core performs? Having 'shell8' in the
$index set artificially inflates the score for serialized runs and artificially
damages the score during maxed-out parallelized runs. If you are actually
interested in seeing how well 'shell8' does on exactly one core, shouldn't you
do the equivalent of 'taskset 1' on it, forcing the child processes to stay on
that single core?
End of quote.
Signed-off-by: Carlos L. Torres carlos.torres@rackspace.com
Addresses issue #4
Quoting original author of this patch as taken from his original from googlecode.com, now issue #4 in Github.
Simply un-limits the 'misc' and 'system' suites.
Half-related thoughts about testing quality:
I'm curious why there's a shell1, shell8, and shell16 set of tests. Aren't the latter two equivalent to './Run -c 8 shell1' and './Run -c 16 shell1'? I think shell8 and shell16 are pointless if this is the case.
At the very least, I think shell8 should be out of the default run (the $index set), because it will essentially give a misleading number if you have more than a single core in the system. Isn't the purpose of the serial run to essentially measure how well the system performs on single-threaded activities? Or perhaps to measure how well a single core performs? Having 'shell8' in the $index set artificially inflates the score for serialized runs and artificially damages the score during maxed-out parallelized runs. If you are actually interested in seeing how well 'shell8' does on exactly one core, shouldn't you do the equivalent of 'taskset 1' on it, forcing the child processes to stay on that single core?
End of quote.
Signed-off-by: Carlos L. Torres carlos.torres@rackspace.com