Phased Transactional Memory Dan Nussbaum Scalable Synchronization - - PowerPoint PPT Presentation

▶
phased transactional memory
SMART_READER_LITE
LIVE PREVIEW

Phased Transactional Memory Dan Nussbaum Scalable Synchronization - - PowerPoint PPT Presentation

Apr 07, 2024 45 likes •256 views

Phased Transactional Memory Dan Nussbaum Scalable Synchronization Research Group Joint work with Yossi Lev and Mark Moir Sun Microsystems Labs August 16, 2007 1 1 Transactional Memory (TM) Replace locks with atomic sections.

slide-1
SLIDE 1

1

Dan Nussbaum Scalable Synchronization Research Group Joint work with Yossi Lev and Mark Moir Sun Microsystems Labs August 16, 2007

Phased Transactional Memory

1

slide-2
SLIDE 2

Su n C

  • n

fiden t ial: I n t er n al O n ly

2

Transactional Memory (TM)

  • Replace locks with atomic sections.
  • (Word-based.)
  • Hardware or Software?

> Software (STM) is cheaper and more flexible. > Hardware (HTM) is faster.

  • Hybrid Transactional Memory (HyTM) gets best of

both worlds.

> Common case in hardware -- fast. > Uncommon case in software – correct. > Make effective use of best-effort hardware (Rock).

slide-3
SLIDE 3

Su n C

  • n

fiden t ial: I n t er n al O n ly

3

Hybrid Transactional Memory (HyTM)

  • HyTM approach: compiler plus library.
  • Two code paths:

> Hardware path attempts to use transactional hardware.

–Fast. –Transactions don't always succed:

– Resource limitations. – “Difficult” instructions. – Contention.

> Software path contains calls into an STM library.

–Slower. –Take this path whenever the hardware comes up short.

slide-4
SLIDE 4

Su n C

  • n

fiden t ial: I n t er n al O n ly

4

HyTM: Instrument Hardware Path

  • Problem: TM hardware unaware of software txns.
  • Solution: make hardware transactions aware of

software transactions, by augmenting hardware path:

txn_begin; if(!canHardwareRead(&X)) txn_abort; Y = X + 5; ==> tmp = X; if(!canHardwareWrite(&Y)) txn_abort; Y = tmp + 5; txn_end;

slide-5
SLIDE 5

Su n C

  • n

fiden t ial: I n t er n al O n ly

5

Phased Transactional Memory

  • Arrange to only be executing in a single mode at a

time, system-wide.

> HARDWARE, SOFTWARE, (others).

  • Partition time into phases.
  • When in HARDWARE mode, use the hardware path.

> Don't have to allow for concurrent execution of software

transactions: minimal overhead.

  • When in SOFTWARE mode, use the software path.

> Don't have to allow for concurrent execution of hardware

transactions: fewer constraints on STM.

slide-6
SLIDE 6

Su n C

  • n

fiden t ial: I n t er n al O n ly

6

PhTM Prototype: Mode Transitions

  • Start out in HARDWARE mode, until some transaction (T)

has to run in software.

  • Switch to SOFTWARE mode, making sure that no

hardware transactions are still running.

  • Run in SOFTWARE mode for a while.

> Allow other transactions to start up in SOFTWARE mode.

  • Switch back to HARDWARE mode.
slide-7
SLIDE 7

Su n C

  • n

fiden t ial: I n t er n al O n ly

7

if (FirstTryInHardware()) { HW: chkpt(F); HWPostCheckpoint(); <== if (mode != HARDWARE) fail; <body> commit(); } else { while (!<try body with STM>) { F: if (!RetryInSoftware()) goto HW; } }

PhTM Prototype: Schema

slide-8
SLIDE 8

Su n C

  • n

fiden t ial: I n t er n al O n ly

8

Experimental Set-Up

  • STM-only experiments: E25K.

> Big (144-core) SMP.

  • Transactional hardware: simulator.

> Wisconsin GEMS/ruby/LogTM (Simics-based). > Modified LogTM to better reflect best-effort constraints.

slide-9
SLIDE 9

Su n C

  • n

fiden t ial: I n t er n al O n ly

9

Benchmarks

  • Transactified Berkeley DB Lock subsystem.

> Every thread repeatedly locks and unlocks its own object. > Ought to scale perfectly.

  • Red-Black Tree.

> Tree is half full. > 20% inserts, 20% deletes, 60% lookups. > On larger machines, contention is significant.

slide-10
SLIDE 10

Su n C

  • n

fiden t ial: I n t er n al O n ly

10

Berkeley DB: STM-only

slide-11
SLIDE 11

Su n C

  • n

fiden t ial: I n t er n al O n ly

11

Berkeley DB: Simulations

slide-12
SLIDE 12

Su n C

  • n

fiden t ial: I n t er n al O n ly

12

RedBlackTree: STM-only

slide-13
SLIDE 13

Su n C

  • n

fiden t ial: I n t er n al O n ly

13

RedBlackTree: Simulations

slide-14
SLIDE 14

Su n C

  • n

fiden t ial: I n t er n al O n ly

14

Conclusions

  • First-cut PhTM implementation already performs

pretty well.

> TL2 looks like best choice for PhTM's software phase.

  • With a bit more work, we hope to close the gap

between PhTM and pure hardware even further.

slide-15
SLIDE 15

Su n C

  • n

fiden t ial: I n t er n al O n ly

15

Future Work

  • Performance Improvements.

> Improve phase management strategy. > Improve contention control strategy. > Inline more of the fast path. > Compiler optimizations.

  • More than just two (HARDWARE, SOFTWARE) modes.

> Requires a more generalized approach (see paper).

> HYBRID mode. > SEQUENTIAL mode.

slide-16
SLIDE 16

Su n C

  • n

fiden t ial: I n t er n al O n ly

16

References

  • HyTM Paper (ASPLOS 2006)

> http://research.sun.com/scalable/pubs/ASPLOS2006.pdf

  • TL2 Paper (DISC 2006)

> http://research.sun.com/scalable/pubs/DISC2006.pdf

slide-17
SLIDE 17

Su n C

  • n

fiden t ial: I n t er n al O n ly

17

Acknowledgements

  • Dave Dice and Nir Shavit (TL2).
  • Brian Whitney (E25K).
  • Peter Damron (Compiler).
  • Sasha Fedorova and Victor Luchangco

(Discussions).

  • Kevin Moore (Simulator).
slide-18
SLIDE 18

18

Yossi Lev, Mark Moir and Dan Nussbaum yosef.lev@sun.com mark.moir@sun.com daniel.nussbaum@sun.com

18

slide-19
SLIDE 19

Su n C

  • n

fiden t ial: I n t er n al O n ly

19

PhTM Prototype: Mode Transitions (2)

ModeIndicator = <mode, deferredCount, undeferredCount>

  • Transactions waiting to run in SOFTWARE mode increment
  • deferredCount. Eventually one of them sets mode=SOFTWARE.
  • Transactions that come into being when mode==SOFTWARE and

deferredCount>0 increment undeferredCount and then run in

software.

  • Transactions that come into being when mode==SOFTWARE and

deferredCount==0 wait for mode to change to HARDWARE.

  • All software transactions decrement appropriate count after

they commit. The last of these sees deferredCount==0 &&

undeferredCount==0, and sets mode=HARDWARE.

slide-20
SLIDE 20

Su n C

  • n

fiden t ial: I n t er n al O n ly

20

PhTM: Generalized Approach

  • Many possible modes.

> HARDWARE, SOFTWARE, HYBRID, SEQUENTIAL, ...

  • Managing transitions between modes.

> No interference between one phase and the next. > When to switch; which mode to switch to?

slide-21
SLIDE 21

Su n C

  • n

fiden t ial: I n t er n al O n ly

21

PhTM: Generalized Approach (cont.)

  • ModeIndicator=<mode, mustFinishThis, otherTxns,

nextMode, mustFinishNext, version>

  • Collect candidates for next mode.

NextMode=<next Mode>; mustFinishNext++

  • Mode Transition

> Only OK when mustFinishThis==0 && otherTxns==0

mode=nextMode; nextMode=NONE; mustFinishThis=mustFinishNext; mustFinishNext=0; version++;