SAS performance on Sun Fire[TM] X4450 servers and Sun Blade[TM] X6450 blade servers running Solaris[TM] 10 could be slower than expected

Asset ID:	1-71-1019712.1
Update Date:	2012-07-06
Keywords:

Solution Type Technical Instruction Sure

Solution 1019712.1 : SAS performance on Sun Fire[TM] X4450 servers and Sun Blade[TM] X6450 blade servers running Solaris[TM] 10 could be slower than expected

Applies to:

Sun Blade X6450 Server Module - Version Not Applicable to Not Applicable [Release N/A]
Sun Fire X4450 Server - Version Not Applicable to Not Applicable [Release N/A]
Solaris SPARC Operating System - Version 10 3/05 to 10 8/11 U10 [Release 10.0]
All Platforms

Goal

Sun Fire X4450 Systems and Sun Blade X6450 Systems, which have Intel(R) Xeon(R) MP 7400 series processors may experience SAS performance issues if running Solaris[TM] 10

Performance for CPU/memory intensive applications could be slower than expected due to BugID 6726459.

Fix

Steps To Follow:

SAS users running applications on Solaris 10/x64 on systems utilizing the Intel(R) Xeon(R) Processor MP 7400 series may experience a reduction in performance of CPU intensive applications.

Systems with Intel(R) Xeon(R) Processor MP 7400 series (psrinfo -pv reports family 6 model 29 all step) running Solaris 10 10/08 might experience reduced performance and increased power consumption. This might occur due to an issue where CPUs do not quiesce, preventing power management while idle. No error message is displayed.

The issue is described in <SunBug 6726459>

<SunBug 6726459> : i86_mwait Function does not function as designed

This is addressed in Solaris 10 Update 7.

A workaround is described in the Solaris 10/08 (Update 6) release notes but can be used for all Solaris 10 releases up to and including Update 6

Workaround:

Add the following line to the /etc/system file and then reboot:

set idle_cpu_prefer_mwait=0

Here are a list of DO and DO NOT items to check:

- Check for Intel® Xeon® Processor MP 7400 series with psrinfo(1M) to see if it is similar to this example:

bash-3.00# psrinfo -pv

The physical processor has 6 virtual processors (0 4-8)

x86 (chipid 0x0 Genuine Intel family 6 model 29 step 1 clock 2400 MHz) Intel(r) CPU @ 2.40GHz

Check for the Solaris 10 release (Example below shows Update 5):

bash-3.00# cat /etc/release

Solaris 10 5/08 s10x_u5wos_10 X86

Use is subject to license terms.

Assembled 24 March 2008

If running Solaris 10 Update 6 or lower, OR any Solaris 10 release where <SunBug 6726459> is specifically not mentioned in the Bugs fixed section of the release notes, add the above workaround to /etc/system and reboot.

If there are further questions, contact Oracle Support.

DO NOT

Add the mwait /etc/system above change if running any any processors other than the Intel(R) Xeon(R) Processor MP 7400 series. This includes any UltraSPARC, SPARC, AMD Opteron or other Intel processors (i.e.: Intel dual or quad core processors).

If running non Intel(R) Xeon(R) Processor MP 7400 series and the mwait setting above is enabled in /etc/system, disable the change and reboot.

Persist the change if <SunBug 6726459> is addressed as per the Solaris release notes for the update release that is currently installed. Remove the /etc/system change above and reboot. The kernel fix is available in Solaris 10, Update 7 at which time the workaround should be removed.

Sample performance data without workaround - Oracle internal information

Here is a sample of performance differentials without the workaround. Customer can be told if they ask but the information should not be emailed or published.

FYI- i recently did some sas testing on the new intel dunnington (six core) processors. while the previous quad core (tigerton) processors in my 4450/tucani clocked in a bit higher (and thus should have better raw performance), dunnington performance was surprisingly poor - up to 6-8X times slower. This was due to an existing bug

Sample test times *before* the workaround:

Cumulative test time - 46 tests summed

tigerton: 4 hrs, 4 min

dunnington: 9 hrs, 26 min

Most tests were 2-3X slower, some worse. one test, a general linear model (one of the threaded tests but both tests clamped to 4 threads), went fairly psychotic on dunnington:

beverage2

tigerton: 10 min

dunnington: 1 hr, 2 min

With the workaround, performance was in line as expected (accounting for the difference in clock rate between tigerton and dunnington)

Attachments

This solution has no attachment