MetaTMTxLinux: Transactional Memory For An Operating System

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-gtXbegin, Unlock-gtXend
• 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
• IPC1 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?