MetaTMTxLinux: Transactional Memory For An Operating System - PowerPoint PPT Presentation
1 / 27
Title:
MetaTMTxLinux: Transactional Memory For An Operating System
Description:
Hany E. Ramadan, Christopher J. Rossbach, Donald E. Porter and Owen S. Hofmann ... Serializability: transactions appear to execute serially, the steps of one ... – PowerPoint PPT presentation
Number of Views:27
Avg rating:3.0/5.0
Title: 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?
Recommended
CrystalGraphics Presentations
