1. zSeries Update
2. Update to High CPU APAR
1. zSeries Update
In the last Cheryl’s List (#50), I discussed a problem with some types of work that did not achieve their expected capacity when running on a z900 processor. Fortunately, great strides have been made since then.
The z900 design change to separate the Data cache and Instruction cache for each CP affected some programs, some quite significantly. The cache line size is 256 bytes. If you modify something within a line that has already been pulled into the instruction cache, it must be moved back over to the data cache. The invalidation takes some overhead.
The last Cheryl’s List mentioned a problem with a Natural program. It turned out to be the way the program was coded. Changing the program resolved the issue. IMS log archiver, DFSUARC0, and ADRSSU (DSS) also had problems and are currently being investigated by IBM.
The most problems reported were with SAS. SAS and IBM worked closely on the problem to resolve it. It seems that SAS had some prolog code that was less than 256 bytes where data was modified within a cache line that also contained instructions. This occurred for every function call in SAS and caused quite a bit of overhead on the z900. SAS provided two zaps to change this logic, that, in most cases, completely solved the problem:
For V8: www.sas.com/service/techsup/unotes/SN/004/004291.html
For V6: www.sas.com/service/techsup/unotes/V6/G/G952.html
The good news is that these also improve SAS run times on the G5 and G6 processors by about 5%. It might improve SAS on the MP3000, but no tests have been run at this time.
I said it solved the problem “in most cases” because two sites still tell me that their test programs were improved after the zaps, but not by as much as expected. But, since these were both very small loop programs, I’m not sure that they’re indicative of typical SAS workloads. If you see any unexpected results after moving to the z900 processors, be sure to notify IBM or SAS (and me!).
For your own programming, use reentrant code whenever possible, and watch out for very high use, very tiny, non-reentrant routines (less than 256 bytes). For an interesting discussion of considerations on coding for D-cache and I-cache, see the IBM-Main archives at <http://bama.ua.edu/archives/ibm-main.html> and search for a string of entries with ‘z/Architecture I-cache’ in the heading.
(As always, for a tool to measure the performance of a new processor or software change, don’t forget our software product, BoxScore <http://www.watsonwalker.com/ boxscore.html>. It can tell you exactly which programs are not meeting expectations, and those that are exceeding expectations as well.)
2. Update to High CPU APAR
In Cheryl’s List #45 (July), I discussed APAR OW44517 (After OW39132, IEAVEOR (IOC003) may not decrement ASCBTCBS marked as HIPER (07/17/01)). This related to performance degradation and/or high LPAR management time (33 MIPS to 69 MIPS in uncaptured time for one site). Many sites ran into the problem and applied the fix for the APAR. Kathy Walsh in session 2500 at SHARE pointed out that APAR OW46338 is a PE of OW44517. So if you applied OW44517, then also apply OW46338 (R5+, 1/2/01).
Stay tuned!