By: Steve Munroe.
PowerLinux is Linux, one of several hardware platforms that Linux supports. Other Linux platforms include S390, ARM, Intel IA32 and x86_64, and a wide variety of the special purpose or embedded use processors.
When I work with customers and independent software developers, this concept of being the same (Linux is Linux) and simultaneously different (platform) can be confusing. Some want to be reassured that PowerLinux is “standard Linux”; to that, the short emphatic answer is yes. Others want to understand the differences that derived from the underlying POWER platform. For example, I am often asked how the POWER platform is better/faster/stronger then other platforms.
In my job as PowerLinux Toolchain Architect, I focus on how to use standard Open Source GNU/Linux tools to get the best results from the PowerLinux platform. Like any tool, achieving the best result requires using and applying those tools correctly/appropriately. Because of the unique attributes of the POWER platform, unique POWER tools are sometimes required to get the deep understanding necessary for the best results.
When I work with customers the questions of “what is the same?”, “what is different?” and “why should I care?” come in many discussions. And this brings us back to title of this blog: “Zen and the art of PowerLinux performance.” I can't avoid answering these questions, and Zen tries to answer similar existential questions.
1. Appearance or Form
2. Nature or Character
3. Entity or Embodiment
PowerLinux is Linux, built from the same open-source source packages using the same tools as any other Linux platform and available from multiple Linux distributions. But its Nature/Character are unique to its RISC based, register rich, load/storage architecture, defined by the Power Instruction Set Architecture (PowerISA). And within the Power family the single PowerISA can have more than one Embodiment -- for example different CHIP design generations or Embedded vs Server design points.
For this blog, I will focus on IBM POWER servers which are designed and tailored for a range (entry-level to large multi-draw systems) of configurations with the capability for massive virtualization within a single server. The Server Embodiment leads to a number design trade-offs that drives both the detail structure of the Processor Cores and Chips, AKA micro-architecture, and the structure of how the processors connect to and interact with the rest of the system (other processors, memory, IO, Accelerators, …)
After Appearance, Nature, and Embodiment we have:
4. Power or Potency/Ability
5. Influence or Function/Activity
This naturally leads to some bad puns... I will resist the urge to inflict those on you now... and additional topics of how to apply the available tools to maximize the Potency/Ability of the PowerLinux platform.
After Power and Influence we have:
6. Internal/Primary cause
7. Indirect/Secondary Cause
8. Latent Effect
Which leads to a discussion of the key attributes of the Power Architecture and core design. The attributes like the instruction set and format, number and type of registers, data formats in storage and registers are direct or primary attributes of the PowerISA and direct implications of the structure of programs (as defined but the Application Binary Interface).
Other attributes are indirect or secondary, like page and cache line size, super-scalar and out-of-order execution, weakly consistent memory ordering, and atomic reservations and acquire/release semantics. Most programs and programmers pay little attention to these attributes but they are important for developers of threaded/parallel programs.
Finally, there are latent effects caused or allowed by the primary and secondary attributes that are reflected in the design of the processor core. For example, the number and types of function pipelines (fixed-point, Load/Store, floating point, vector, decimal floating point) drive design trade-offs about width of instruction fetch, dispatch and issue, and pipeline latency. How this works in the hardware is of keen interest to compiler and JIT developers. Complexity and core frequency force the core design to add prediction mechanisms to avoid stalls, but miss predictions result in hazards (longer stalls when they occur). Miss predictions and hazards are of keen interest to performance/profiling tools and single threaded performance vs multi-thread throughput trade-offs associated with SMT.
Primary/secondary cause and latent effects lead to:
9. Manifiest effect (Recompense)
Which includes tangible effects that emerge as an expression of the previous attributes.
And finally we complete with circle with:
10. Complete Fundamental Whole
Which indicates that the other nine suchnesses; from form/appearance to manifest effect are consistently interrelated.
In blog entries to follow, I will try to weave my knowledge and experience with specific examples of what, why, how of POWER and PowerLinux and hopeful provide interesting and useful answers to these important questions.