Porting OpenVMS to the Itanium Processor Family

Transcription

1 Porting OpenVMS to the Itanium Processor Family Andy Goldstein (acknowledgements to OpenVMS Engineering Clair Grant) October, Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice

2 We will port OpenVMS to the IA64 architecture and ship a production quality release in June 25 th, 2001 Hewlett-Packard 2

3 hp OpenVMS Roadmap HP AlphaServer EV68 EV7 EV79 Sell at least until 2006; support at least until 2011 Itanium -based HP server Itanium 2 processor Madison Itanium -based system upgrades Itanium -based system upgrades HP OpenVMS Alpha Version Version Version hp OpenVMS I64 V8.2 (2004) (3 rd Release Production Quality) & hp OpenVMS Alpha V8.2 HP OpenVMS Industry Standard 64 Boot Jan 03 OpenVMS I64 E8.0 H103 Eval. Release OpenVMS I64 E8.1 H203 Eval. Release Future releases providing continued enhancement & support Platform transition period 3

4 hp OpenVMS Industry Standard 64 (I64) Release Roadmap H103 H203 H104 H204 1 st Boot on i2000 system, January 31, :31 PM EST Boot on rx2600 system (First Ship platform), March 17, 2003 First Ship H103: hp OpenVMS I64 E8.0 Mako Evaluation Release Audience: Selected ISVs and Partners OpenVMS Itanium Operating System, Monitor Utility Networks: DECnet Phase IV, TCP/IP Development Tools: Cross Linker, Cross Librarian, Native Debugger Cross Compilers: C, C++, BLISS, FORTRAN, IMACRO Internal releases H203: hp OpenVMS I64 E8.1 Jaws Evaluation Release Audience: Key ISVs, Partners, Early Adopters Limited cluster functionality (4 nodes) Native Compilers: C, C++, BLISS, FORTRAN, IMACRO, Pascal, BASIC, COBOL Additional Language Support: JAVA Additional Layered Products Networks, Data Serving, Security, ebusiness Integration, Application Development Production Quality External releases HP OpenVMS I64 V8.2 4

5 Porting Goals Provide an operating system environment, development tools, and documentation to make porting as easy as possible Full port of the Operating System, Runtime Libraries, development tools and most layered products Recompile, relink, requalify Use our experiences porting the operating system to make it easier for others to port their applications Internal layered product groups, partners, and customers 5

6 Porting Philosophy This is not a bug for bug compatible coding exercise. We are doing much, much more. First, we are not just porting to the Itanium architecture; we are making OpenVMS more portable. Second, we are improving code maintainability (and sometimes performance) by replacing VAX assembler code when appropriate. Third, we are making the system more open to the possibility of exchanging code with other systems, especially analysis tools. (This even helped us with some early debug.) 6

7 Big Challenges for the Base OS No Alpha Console Booting Device Discovery Interrupts TLB miss handler Different primitives in CPU Register Conventions Exception Handling Atomic Instructions Process Context No Alpha PALcode VAX Queue Instructions VAX Registers IPL and mode change Plus, we decided to change calling standard object language image format 7

8 It s All in the Software Application Application Application SW OpenVMS OpenVMS OpenVMS FW Console Console PALcode Console HW VAX Alpha Itanium Processor 8

9 Console Intel-architected boot environment In the FAT partition VMS_LOADER.EFI IPB.EXE Operating system interface to ACPI data Boot drivers for SCSI and IDE VMS uses standard PAL/SAL console interfaces to get Translation buffer info Clock frequency Machine Check Vectors. 9

10 Alpha PALcode Replacement The following are all managed in the PAL on Alpha; VMS does the work on Itanium VAX queue instructions (compilers generate OS calls) VAX internal processor registers AST and software interrupt support IPL Swap context 10

11 CPU Primitives Different register conventions R8/return status; R12/stack pointer Compilers do the translation More registers IMACRO automatically replaces LDL/STC sequences Memory fence replaces memory barrier Compilers have builtins for most functions 11

12 Calling Standard Intel Calling Standard plus VMS extensions Different register conventions Unwind data Affected areas Exception handling Signaling Compilers LINKER Debuggers Non-standard routine calls Swap context Kernel Processes enhanced to provide context-aware routines for all modes converted DCL, DECnet, XQP, RMS, 12

13 Lines of Code Perspective New Recompile OpenVMS on Itanium -based systems Porting effort is very focused on a few areas of the system. 13

14 How did it go? Boot Contest on i2000 Scheduled: 12 weeks to boot (given good linked images) Actual: 10 weeks (Jan. 31, 2003) Boot on rx2600 Scheduled: 6 weeks Actual: 6 weeks and 1 day (Mar. 17, 2003) The effort and difficulty have been about as expected No huge surprises New Calling Standard and Object Language at least 50% of the project 14

15 Current Itanium Porting Status We're Done! (modulo a couple of bugs) Still Using Cross Tools to Build C, C++, Bliss, imacro, IA64 Assembler cross compilers Cross Linker Cross SDA allows for IA64 dumps analysis on Alpha Booted on All supported systems Several that aren't supported yet 15

16 Current Itanium Porting status What is not yet working (October 6) Edit/Teco Delta Debugger not in V8.2 System Code Debugger (SCD) INSTALL performance features Security Server Registry Server ACME Server Shadowing Fibre Channel Boot Cluster Satellite Booting not in V8.2 16

17 OpenVMS Alpha and IPF Performance Comparison Andy Goldstein (acknowledgements to OpenVMS Engineering Greg Jordan) Hewlett-Packard 2004 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice

18 Overview The purpose of this presentation is to provide you with appropriate expectations of the performance of OpenVMS on Integrity platforms. The performance of various Integrity platforms will be compared with a variety of current Alpha platforms. 18

19 IPF/Alpha Performance Comparison The Basics CPU Memory IO OpenVMS Operating System Performance Various Improvement Successes Performance Conclusions 19

20 CPU Integer test program Integer test program 600 Rating More is better rx GHz/3mb rx GHz/6MB ES45 1GHz GS GHz 20

21 SETI Time to Process a Work Unit CPU Seconds Less is better rx GHz rx GHz rx MHz DS25 1GHz XP MHz 21

22 Memory Bandwidth MEMSpeed Test Program MB/sec rx4640 (mx2) 1.1GHz/4MB rx GHz/3MB rx GHz/6MB rx GHz/6MB ES45 1GHz 0 More is better GS GHz 22

23 Memory Latency Latency (ns) rx GHz/3MB rx GHz/6MB rx GHz/6MB ES45 1GHz GS GHz Less is better 23

24 IO Performance single process (QLogic ISP23xx) 2Gigabit Fiber Channel Card 25,000 20,000 Ops/Sec 15,000 10,000 5,000 ES45 1GHz rx GHz 0 1 Block 4 Block 8 Block 16 Block 32 Block 64 Block More is better 96 Block 127 Block 24

25 IO Performance two processes (QLogic ISP23xx) 2Gigabit Fiber Channel Card 50,000 40,000 Ops/Sec 30,000 20,000 10,000 ES45 1GHz rx GHz 0 1 Block 4 Block 8 Block 16 Block 32 Block More is better 64 Block 96 Block 127 Block 25

26 Gigabit Transmit MBytes/Sec rx GHZ (A6825A - Broadcom 5701) in 64-bit 66 mhz DS25 1GHz (DEGXA - Broadcom 5703) in 64-bit 66 mhz MB/sec DS25 1GHz rx GHz More is better 26

27 Gigabit Transmit CPU Utilization rx GHZ (A6825A - Broadcom 5701) in 64-bit 66 mhz DS25 1GHz (DEGXA - Broadcom 5703) in 64-bit 66 mhz 100% CPU Utilization 80% 60% 40% 20% DS25 1GHz rx GHz 0% Less is better 27

28 Gigabit Transmit/Receive MBytes/Sec rx GHZ (A6825A - Broadcom 5701) in 64-bit 66 mhz DS25 1GHz (DEGXA - Broadcom 5703) in 64-bit 66 mhz CPU Active MB/sec DS25 1GHz rx GHz More is better 28

29 Gigabit Transmit/Receive CPU Utilization rx GHZ (A6825A - Broadcom 5701) in 64-bit 66 mhz DS25 1GHz (DEGXA - Broadcom 5703) in 64-bit 66 mhz 100% CPU Utilization 80% 60% 40% 20% DS25 1GHz rx GHz 0% Less is better 29

30 System Services X8.2 vs RX4640 faster than ES45 for all points above the line OpenVMS Goal: Continue to move more and more test points above the line and to push the points above the line higher & higher

31 Lock Manager Stress Test Converts/sec (1000s) 4 Processes Active CPUs More is better rx GHz 0-3 rx GHz rx GHz ES45 1GHz GS GHz 31

32 XFC Cached 1 Block IOs Cached IOs/sec 180, , , , ,000 80,000 60,000 40,000 20, Processes More is better rx GHz GS GHz ES40 833MHz 32

33 XFC Cached 4 Block IOs Cached IOs/sec 180, , , , ,000 80,000 60,000 40,000 20, Processes rx GHz GS GHz ES40 833MHz More is better 33

34 XFC Cached 16 Block IOs Cached IOs/sec 180, , , , ,000 80,000 60,000 40,000 20, Processes rx GHz GS GHz ES40 833MHz More is better 34

35 RMS1 (RAMdisk) IOs/Sec ES45 1GHz rx GHz Processes More is better 35

36 rx4640 vs. rx (mx2 module) IOs/Sec rx GHz rx GHz rx GHz (mx2) 0 4 Proce sse s 8 Proce sse s Processes More is better 36

37 OpenVMS InfoServer CPU Usage CPU Utilization 80% 60% 40% 20% (Advanced Development Project) rx MHz (April) rx MHz (June) rx GHz (Estimate) ES45 1GHz 0% Active Client Loads Backup/Image from InfoServer to local device Less is better 37

38 Apache Requests Per Second Simple CGI Script ES45 1GHz rx GHz 38 Requests/Sec Concurrency 1 Concurrency 2 Concurrency 4 Concurrency 8 More is better

39 Apache CPU Utilization Concurrency 8 Simple CGI Script ES45 1GHz rx GHz CPU Utilization Concurrency 1 Concurrency 2 Concurrency 4 Less is better

40 Various Improvement Successes Heavy IO loads to disks performed very poorly rx2600 2,084 IOs/sec Spinlock Analysis showed VERY heavy usage of MMG for the IPF which didn t appear for the Alpha Further Analysis showed IPF was never caching any KPB structures. One line fix -> rx ,999 IOs/sec 40

41 OTS$MOVE and OTS$MOVEM OTS$MOVE and OTS$MOVEM are low level routines called by compilers to move data. Macro calls this for MOVC3 and MOVC5 instructions C calls this routine for memcpy BLISS call this for ch$move Highly optimized versions of these routines have recently been integrated into OpenVMS This resulted in significant performance improvements for tests that did heavy memory copies The RMS1 test improved by about 15% for single stream and by about 38% for 4 streams! 41

42 Queue Instructions The various VAX architecture queue instructions were initially implemented as system services These needed to be done in Kernel mode to insure the operation was atomic We knew they would be slow and they were as shown by a small test program doing insque/remque in loop. ES45: 0:05.21 rx2600: 2:58.21 (34 times slower) The implementation of the queue instructions has been changed to no longer use the system service dispatcher They now use the EPC (Enter Privileged Code) rx2600: 0:14.59 (< 3 times slower) 42

43 Areas that are Slower on IPF There are several areas where the equivalent operations on IPF systems are slower Queue Instructions Various PAL calls which now go through the system service dispatcher Exception Handling Exceptions Frames much larger Finding Exception Handlers takes longer Images also are typically 3 times as large This can impact image activation time Requires More IO Increase page faults 43

44 Projected Performance Crossover Point predicted two years ago OpenVMS on EV7 EV7z

45 Conclusions 1.5GHz rx4640 Integrity systems perform similarly to 1GHz ES45 Alpha systems There will continue to be improvements in both the OS and Compilers prior to the release of OpenVMS V8.2 OS improvements coupled with future hardware speed ups will allow OpenVMS on IPF to out perform OpenVMS on Alpha 45

46 46