1 MetaTM/TxLinux: Transactional Memory For An Operating System Hany E. Ramadan, Christopher J. Rossbach, Donald E. Porter and Owen S. Hofmann Presenter: Zhong Zhou CSE Department University of Connecticut

2 Outline Introduction & Background Architectural Model Interrupts and Transactions Stack memory and Transactions Modifying Linux to use HTM Evaluation Conclusions

3 Introduction What is Transaction? A finite sequence of machine instructions, executed by a single process, satisfying the following two conditions Serializability: transactions appear to execute serially, the steps of one transaction never appear to be interleaved with the steps of another. Atomicity: each transaction makes a sequence of changes to shared memory, when it completes, it either commits, make all changes visible to others, or it abort, causing its changes to be discarded.

4 Transactional memory A multiprocessor architecture for memory access synchronization as conventional mutual exclusion technique Basic instruction for manipulating transaction status Commit Abort Validate Basic primitive instruction for accessing memory Load transactional Load transactional-exclusive Store transactional

5 Why Transaction memory? Problem with Lock-based code Deadlock Convoying Priority inversion Transaction memory: Reduce programming complexity without sacrificing performance STM: software transaction memory HTM: hardware transaction memory

6 Main Contribution Examination of the architectural support necessary for an operation system to use HTM Creation of a transactional operating system Examination of the characteristics of transactions in TxLinux

7 Architecture Model Transaction semantics

8 Managing multiple transactions Stack based: independent transaction model XPUSH: Suspend the current transaction, saving its current state. XPOP: Restore the previously xpushed transaction. Allowing the suspended transaction to resume

9 Contention management Many content manage strategies have been implemented Polite, Karma, Eruption, et al. A new policy (size matters) Favors the transaction that has the large number of unique bytes read or written in its transaction working set

10 Backoff If conflict occurs between transactions, with high probability, it will happen again if immediate restart these transactions. Backoff mechanism is needed here Exponential backoff Linear backoff Random backoff

11 Interrupts and Transactions Interrupt handling background The top-half interrupt handler Disable all interrupt with equal and lower priorities Relatively short execution time, push as much work as possible to bottom-half The bottom-half interrupt handler

12 Observations for Interrupt handling Observations Transaction length: usually large Interrupt frequency: relative high Interrupt routing limitations: less flexible

13 Interrupt handling in TxLinux Start with XPUSH to suspend the currently running transaction Interrupt handler is allowed to start new, independent transaction Interrupt return path ends with an XPOP instruction

14 Stack memory and Transaction Stack memory is shared between thread in the Linux kernel On the X86 architecture, Linux thread share their kernel stack with interrupt handlers. The sharing of kernel stack address requires stack addresses to be part of transaction working sets to ensure isolation

15 Transactions that span activation frames Support independent Xbegin and Xend instruction. Xbegin and Xend can be called in different stack frame Example:

16 Live stack overwrite problem(1) One example:

17 Live stack overwrite problem(2) This problem stems from Calls to xbegin and xend occur in different stack frame The x86 trap architecture reuses the current stack on interrupt that does not change privilege level A transaction that is suspended can restart Solutions Change the interrupt handler stack to avoid the overwrite problem.

18 Transactional dead stack problem(1) One example:

19 Transactional dead stack problem(1) Solution Stack-based early release: During an active transaction, any time the stack pointer is incremented, if the new value of the stack pointer is on a different cache line from the old one, then, the processor releases the old cache lines from the transactional line

20 Modifying Linux to use HTM Spinlocks Lock->Xbegin, Unlock->Xend Atomic instructions Seqlocks Regions protected by seqlock loops are protected by a transaction in TxLinux Read-copy-update

21 Performance evaluation Simulation settings Split instruction\data L1 cache: 16KB, 4- way associative, 64-byte cache line Unified L2 cache: 4MB, 8-way associative, 64-byte cache line Main memory: 1GB IPC:1 instruction per cycle

22 Cache miss rates

23 System time

24 Contention management

25 Backoff policy

26 Conclusions HTM has the potential to greatly simplify the operating system synchronization while retaining a high degree of concurrency Examine several aspect of HTM implementation and policies Polka contention management policy is effective Backoff policy is important, both linear and exponential backoff work well

27 Thank You! Q & A?