search

jonghyeopkim / byte-unixbench

Automatically exported from code.google.com/p/byte-unixbench
0 stars 0 forks source link

Can't do default run completely with > 16 CPUs #4

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 ste...@uplinklabs.net on 6 Mar 2011 at 11:58

GoogleCodeExporter commented 9 years ago 
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 ste...@uplinklabs.net on 6 Mar 2011 at 12:38

Attachments:

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

Original comment by frederik...@googlemail.com on 2 Aug 2011 at 9:49

GoogleCodeExporter commented 9 years ago 
The fix worked on a 24 core-machine smoothly.

Original comment by frederik...@googlemail.com on 19 Aug 2011 at 8:15

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
The fix worked for me on a Dual E5-2650 (8 core/16 threads)

Original comment by m...@aod.net on 31 Mar 2012 at 8:21

GoogleCodeExporter commented 9 years ago 
How to apply this patch on centos ?

Thanks

Original comment by webhost...@gmail.com on 20 May 2012 at 3:25

GoogleCodeExporter commented 9 years ago 
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 geckol...@gmail.com on 11 Apr 2013 at 1:41

GoogleCodeExporter commented 9 years ago 
Fix worked on a 32 core Cisco UCS box. Thanks!

Original comment by e.shane....@gmail.com on 24 Sep 2013 at 5:09