Can't do default run completely with > 16 CPUs

[GoogleCodeExporter]

What steps will reproduce the problem?
Run with the default command line ('./Run') on a machine with > 16 CPUs.

What is the expected output? What do you see instead?
Expected would be a run with a single serial run, followed by an N-way parallel 
run. Instead, it skips all of the tests because of a hardcoded limit of '16'.

What version of the product are you using? On what operating system?
v5.1.3 on Linux 2.6.32.

Please provide any additional information below.
Is there a reason for the hardcoded limit of 16-way parallelism? It seems 
reasonable to be able to match the number of processors detected in the system.

Original issue reported on code.google.com by [email protected] on 6 Mar 2011 at 11:58

[GoogleCodeExporter]

Attached is a potential fix for the issue. 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?

Original comment by [email protected] on 6 Mar 2011 at 12:38

Attachments:

• fix-limitation.patch

[GoogleCodeExporter]

Same Problem on a 24-core machine. Iam using UnixBench 5.1.3. I will try if the 
fix will help.

Original comment by [email protected] on 2 Aug 2011 at 9:49

[GoogleCodeExporter]

The fix worked on a 24 core-machine smoothly.

Original comment by [email protected] on 19 Aug 2011 at 8:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The fix worked for me on a Dual E5-2650 (8 core/16 threads) 

Original comment by [email protected] on 31 Mar 2012 at 8:21

[GoogleCodeExporter]

How to apply this patch on centos ?

Thanks

Original comment by [email protected] on 20 May 2012 at 3:25

[GoogleCodeExporter]

In reply to comment #6

Download fix-limitation.patch in the same directory as the Run script, and type:

  patch Run fix-limitation.patch 

That's it!

Original comment by [email protected] on 11 Apr 2013 at 1:41

[GoogleCodeExporter]

Fix worked on a 32 core Cisco UCS box. Thanks!

Original comment by [email protected] on 24 Sep 2013 at 5:09