1 / 13

A Case for Deconstructing Hardware Transactional Memory Systems

Explore the concept of deconstructing Hardware Transactional Memory (HTM) systems into interchangeable components to aid in refinement and extend usability beyond traditional Transaction Memory (TM) applications. The approach involves breaking down HTMs for better optimization and exploring innovative applications like deterministic replay for debugging and security. The project delves into GRAAS deconstruction, rollback evolution, access check advancements, and recommendations for HW vendors.

miach
Télécharger la présentation

A Case for Deconstructing Hardware Transactional Memory Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Case for Deconstructing Hardware Transactional Memory Systems Mark D. Hill, Derek Hower, Kevin E. Moore, Michael M. Swift, Haris Volos, David A. Wood LogTM Project (www.cs.wisc.edu/multifacet/logtm/) Computer Sciences Dept., Univ. of Wisconsin—Madison September 2007 @ Dagstuhl Seminar 07361 Architects should not develop programming models Instead let’s discuss hardware support

  2. Executive Summary • Transaction Memory promising & Hardware TM (HTM) fast • But HW vendors cautious about HTM • Implementation choices in flux • Ultimate TM success not assured • Thesis: Facilitate TM adoption by deconstructing HTMs into components that are separate, interchangeable, & re-usable • Deconstruction aids HTM refinement • E.g., Special cache  Write buffer  HW logging  SW logging • Deconstruction enables use beyond TM • E.g., Recording for deterministic replay  Deconstruction to promote TM & other models Wisconsin Multifacet Project

  3. Outline (1) Deconstruction Aids HTM Refinement • Herlihy & Moss • GRAAS Deconstruction • Rollback Evolution • Access Check Evolution (2) Deconstruction Beyond TM Wisconsin Multifacet Project

  4. Herlihy & Moss TM (HMTM) • Seminal work • TM data in special cache • No change to coherence protocol • But • Transactions can’t exceed special cache size • Livelock possible • Let’s deconstruct to improve…. Wisconsin Multifacet Project

  5. } Talk Focus A GRAAS (“grass”) Deconstruction • Grouping: Demark a finite set of instructions • Rollback: Undo a set of instructions • Access Summary: Record read/write set • Access Check: Check for conflicts • Scheduling: Choose who executes & when Wisconsin Multifacet Project

  6. Rollback • Save old values (for abort) & new values (for commit) • HMTM: Flush special cache; no register rollback • SLE: Speculative processor • TCC write buffers • LTM/Bulk cache incoherence • LogTM/SigTM log(per-thread in virtual memory) • Aids commit, cache victimization, & thread migration • “Best” design still in flux? Wisconsin Multifacet Project

  7. Access Summary • Summarize read/write sets for detecting conflicts • HMTM special cache • SLE/LTM/LogTM cache states • TCC block/word cache states • Bulk/LogTM-SE/SigTM signatures • “Best” design still in flux? Wisconsin Multifacet Project

  8. Recommendation to HW Vendors • Deconstruct HTMs facilitate TM evolution • Examples from GRAAS deconstruction • Rollback: Write buffer  HW logging  SW logging • Access Summary: Special Cache (States)  Signatures • More Innovations TBD Wisconsin Multifacet Project

  9. Outline (1) Deconstruction Aids HTM Refinement (2) Deconstruction Beyond TM • Deterministic Replay • GRASS Beyond TM • Call for Innovation Wisconsin Multifacet Project

  10. Example: Deterministic Replay • … for debugging, fault-tolerance, & security audits • Existing Flight Data Recorder • Logs 1B/1K-instuctions for conflicting memory accesses • Requires timestamp cache, e.g., 24KB/core • Transactional Flight Data Recorder • Log transaction order – no timestamp cache • Use minimal HW for non-transaction conflicts (if exist) • FDR & TM synergy may help both be adopted Wisconsin Multifacet Project

  11. GRAAS Beyond TM Wisconsin Multifacet Project

  12. Call for Innovation • TM deconstruction aids programming • Can decontruction aid parallel programming models? • Don’t assume symmetric multiprocessor hardware • Let’s dream of • Parallel programming models • Facilatated by new hardware mechanisms Wisconsin Multifacet Project

  13. Executive Summary • Facilitate TM adoption by deconstructing HTMs into components: separate, interchangeable, & re-usable • Deconstruction aids HTM refinement • Deconstruction enables use beyond TM • Deconstruction to promote TM & other models References http://www.cs.wisc.edu/multifacet/logtm/ ./multifacet/papers/tr1594_dtm.pdf ./multifacet/papers/ieeemicro07_flight_data_recorder.pdf Wisconsin Multifacet Project

More Related