Understanding POWER multiprocessors

Abstract

Exploiting today's multiprocessors requires highperformance and correct concurrent systems code (optimising compilers, language runtimes, OS kernels, etc.), which in turn requires a good understanding of the observable processor behaviour that can be relied on. Unfortunately this critical hardware/software interface is not at all clear for several current multiprocessors.In this paper we characterise the behaviour of IBM POWER multiprocessors, which have a subtle and highly relaxed memory model (ARM multiprocessors have a very similar architecture in this respect). We have conducted extensive experiments on several generations of processors: POWER G5, 5, 6, and 7. Based on these, on published details of the microarchitectures, and on discussions with IBM staff, we give an abstract-machine semantics that abstracts from most of the implementation detail but explains the behaviour of a range of subtle examples. Our semantics is explained in prose but defined in rigorous machine-processed mathematics; we also confirm that it captures the observable processor behaviour, or the architectural intent, for our examples with an executable checker. While not officially sanctioned by the vendor, we believe that this model gives a reasonable basis for reasoning about current POWER multiprocessors.Our work should bring new clarity to concurrent systems programming for these architectures, and is a necessary precondition for any analysis or verification. It should also inform the design of languages such as C and C++, where the language memory model is constrained by what can be efficiently compiled to such multiprocessors.

Litmus tests for comparing memory consistency models

“…Some memory models such as PowerPC [12] are non-store atomic and thus allow each thread to observe writes in a different order. These models are not included in the class of models defined in this paper, and they are known to require larger litmus tests with more than two threads.…”

“…We allow a thread to read its own writes early, but do not allow it to read other threads' writes early [1]. Thus, this class of memory models is expressive enough to include most hardware memory models, including Sequential Consistency (SC) [9], Sun's SPARC [15] and Intel's x86 [7], but not non-store-atomic models like PowerPC [12].…”

McVerSi: A test generation framework for fast memory consistency verification in simulation

“…Sequential Consistency (SC) [28], Total Store Order (TSO) [4,29], Release Consistency (RC) [30], POWER [17,4,31] and ARM [4] -as well as operational -e.g. x86-TSO [2] and POWER [32]) -models can be used to describe MCMs formally.…”

Robust architectural support for transactional memory in the power architecture

“…If, however, the larx reads a non-stale value and the subsequent stcx to the same location can place its written value immediately after the value read by the larx in the coherence order for the location, the larx/stcx pair succeeds and updates memory. [12,27,26]. A stcx instruction can succeed as soon as its write is serialized into the coherence order, but before the effects of the write have propagated to the other processors.…”