DHTM: Durable Hardware Transactional Memory
|
|
|
- Stanley Shelton
- 5 years ago
- Views:
Transcription
1 DHTM: Durable Hardware Transactional Memory Arpit Joshi, Vijay Nagarajan, Marcelo Cintra, Stratis Viglas ISCA 2018
2 is here!2
3 is here!2
4 Systems LLC!3
5 Systems - Non-volatility over the memory bus - Load/Store interface to persistent data LLC!3
6 Systems - Non-volatility over the memory bus - Load/Store interface to persistent data LLC System Crashes!3
7 Systems - Non-volatility over the memory bus - Load/Store interface to persistent data LLC System Crashes Crash Consistency - Is the persistent state consistent? - Programming Model: ACID Transactions!3
8 Systems Ensuring failure atomicity for all this computation without - Non-volatility over the memory bus failure-atomic transactions is practically infeasible, if not impossible. LLC System Crashes - Load/Store interface to persistent data Marathe et al. [HotStorage 17] Crash Consistency - Is the persistent state consistent? - Programming Model: ACID Transactions!3
9 Systems Ensuring failure atomicity for all this computation without - Non-volatility over the memory bus failure-atomic transactions is practically infeasible, if not impossible. LLC System Crashes - Load/Store interface to persistent data Marathe et al. [HotStorage 17] Crash Consistency - Is the persistent state consistent? - Programming Model: ACID Transactions How fast can we support ACID?!3
10 ACID Transactions LLC!4
11 ACID Transactions Atomic Visibility LLC!4
12 ACID Transactions Atomic Visibility LLC Atomic Durability!4
13 ACID Transactions Atomic Visibility Locks STM HTM LLC Atomic Durability!4
14 ACID Transactions Atomic Visibility Locks STM HTM LLC Checkpointing S/W Logging H/W Logging Atomic Durability!4
15 ACID Transactions Atomic Visibility Locks STM HTM LLC Checkpointing S/W Logging H/W Logging Atomic Durability!4
16 Atomic Visibility: HTM!5
17 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line R W A = 15 B = !5
18 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line A = 15 B = 20 R 1 W 1 - Version Management: read/write sets in cache!5
19 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line A = 15 B = 20 R 1 W 1 - Version Management: read/write sets in cache - Conflict Detection: piggy back on the coherence protocol!5
20 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line A = 15 B = 20 R W - Version Management: read/write sets in cache - Conflict Detection: piggy back on the coherence protocol - Commit: make updates non-speculative!5
21 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line B = 20 R W - Version Management: read/write sets in cache - Conflict Detection: piggy back on the coherence protocol - Commit: make updates non-speculative - Abort: invalidate write set!5
22 Atomic Visibility: HTM Cache Commercial HTMs [Intel, IBM] Cache Line B = 20 R W - Version Management: read/write sets in cache - Conflict Detection: piggy back on the coherence protocol - Commit: make updates non-speculative - Abort: invalidate write set Write-sets in commercial HTMs limited by the size of the cache.!5
23 Atomic Durability: Logging!6
24 Atomic Durability: Logging Logging for durability [Doshi 16, In-place Values Joshi 17, Shin 17, Ogleari 18] A = 10 B = 20 C = 30!6
25 Atomic Durability: Logging Logging for durability [Doshi 16, In-place Values A = 10 Transaction Log A = 15 Joshi 17, Shin 17, Ogleari 18] - Write a log entry for every update B = 20 C = 30 B = 25!6
26 Atomic Durability: Logging Logging for durability [Doshi 16, In-place Values A = 15 Transaction Log Joshi 17, Shin 17, Ogleari 18] - Write a log entry for every update B = 25 - Commit: Update the values in-place C = 30!6
27 Atomic Durability: Logging Logging for durability [Doshi 16, In-place Values A = Transaction Log Joshi 17, Shin 17, Ogleari 18] - Write a log entry for every update B = Commit: Update the values in-place C = 30 - Abort: Undo any in-place updates!6
28 Atomic Durability: Logging Logging for durability [Doshi 16, In-place Values A = Transaction Log Joshi 17, Shin 17, Ogleari 18] - Write a log entry for every update B = Commit: Update the values in-place C = 30 - Abort: Undo any in-place updates In-place updates in the critical path of commit High memory write bandwidth requirement!6
29 ACID = HTM + Logging Goals: - Support fast commits - Minimise memory bandwidth consumption - Extend the supported transaction size - Maintain the simplicity of commercial HTMs!7
30 DHTM: Durable Hardware Transactional Memory Log Writes LLC!8
31 DHTM: Durable Hardware Transactional Memory Commercial HTM + Hardware Redo Log Log Writes LLC!8
32 DHTM: Durable Hardware Transactional Memory LLC Log Writes Commercial HTM + Hardware Redo Log - H/W Redo Log + Log Buffer Reduced memory bandwidth Fast commits!8
33 DHTM: Durable Hardware Transactional Memory LLC Log Writes Commercial HTM + Hardware Redo Log - H/W Redo Log + Log Buffer Reduced memory bandwidth Fast commits - H/W Log + Sticky State Extended transaction size to the LLC Simplicity of commercial HTM!8
34 DHTM: Log Buffer Log Writes LLC!9
35 DHTM: Log Buffer Redo Log Bandwidth Problem Log Writes LLC!9
36 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes LLC!9
37 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes - multiple stores create multiple log entries LLC!9
38 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes - multiple stores create multiple log entries LLC Solution: Log Buffer!9
39 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes - multiple stores create multiple log entries LLC Solution: Log Buffer - track cache lines being modified!9
40 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes - multiple stores create multiple log entries LLC Solution: Log Buffer - track cache lines being modified - multiple writes coalesced in a log entry!9
41 DHTM: Log Buffer Redo Log Bandwidth Problem - write a log entry for every store Log Writes - multiple stores create multiple log entries LLC Solution: Log Buffer - track cache lines being modified - multiple writes coalesced in a log entry - log entry written to persistent memory on eviction from log buffer!9
42 DHTM: Transaction States!10
43 DHTM: Transaction States Begin Transaction Active!10
44 DHTM: Transaction States End Transaction & Begin Transaction Log Records Persisted Active Commit!10
45 DHTM: Transaction States End Transaction & Begin Log Records In-place Data Transaction Persisted Persisted Commit Active Commit Complete!10
46 DHTM: Transaction States End Transaction & Begin Log Records In-place Data Transaction Persisted Persisted Commit Active Commit Complete Conflict Abort!10
47 DHTM: Commit Example Cache State Cache Line R W Log Buffer Begin_Transaction Write (A=15) In-place Values Transaction Log Read (B) Write (B=25) End_Transaction A = B = C = 30!11
48 DHTM: Commit Example Cache State Cache Line R W Active Log Buffer Begin_Transaction Write (A=15) In-place Values Transaction Log Read (B) Write (B=25) End_Transaction A = B = C = 30!11
49 DHTM: Commit Example Cache State Cache Line R W A = 15 1 Active Log Buffer A Begin_Transaction Write (A=15) In-place Values Transaction Log Read (B) Write (B=25) End_Transaction A = B = C = 30!11
50 DHTM: Commit Example Cache State Cache Line R W A = 15 1 B = 20 1 Active Log Buffer A Begin_Transaction Write (A=15) In-place Values Transaction Log Read (B) Write (B=25) End_Transaction A = B = C = 30!11
51 DHTM: Commit Example Cache State Cache Line R W A = 15 1 B = Active Log Buffer A B Begin_Transaction Write (A=15) In-place Values Transaction Log A = 15 Read (B) Write (B=25) End_Transaction A = B = C = 30!11
52 DHTM: Commit Example Cache State Cache Line R W A = 15 1 B = Commit Active Log Buffer A B Begin_Transaction Write (A=15) In-place Values A = B = Transaction Log A = 15 B = 25 Commit Read (B) Write (B=25) End_Transaction C = 30!11
53 DHTM: Commit Example Cache Cache Line R W A = 15 1 B = State Commit Commit Active Complete Log Buffer A B Begin_Transaction Write (A=15) In-place Values A = B = Transaction Log A = 15 B = 25 Commit Read (B) Write (B=25) End_Transaction C = 30 Complete!11
54 DHTM: Supporting Overflow!12
55 DHTM: Supporting Overflow Problems with Overflow:!12
56 DHTM: Supporting Overflow Problems with Overflow: - Version Management: - global operation on write-set on a commit/abort - overhead infeasible in larger caches (beyond )!12
57 DHTM: Supporting Overflow Problems with Overflow: - Version Management: - global operation on write-set on a commit/abort - overhead infeasible in larger caches (beyond ) - Conflict Detection: - additional metadata to detect conflicts - increased complexity due to NACK based protocols!12
58 DHTM: Supporting Overflow!13
59 DHTM: Supporting Overflow Solution!13
60 DHTM: Supporting Overflow LLC Solution - Version Management: - Overflow List!13
61 DHTM: Supporting Overflow LLC Solution - Version Management: - Overflow List!13 Overflow List A B C
62 DHTM: Supporting Overflow LLC Solution - Version Management: - Overflow List!13 Overflow List A B C
63 DHTM: Supporting Overflow LLC Solution - Version Management: - Overflow List - Conflict Detection: - maintain sticky state on overflow (similar to LogTM) - avoid NACK by restricting overflow to LLC Overflow List A B C!13
64 DHTM: Supporting Overflow LLC Solution - Version Management: - Overflow List - Conflict Detection: - maintain sticky state on overflow (similar to LogTM) - avoid NACK by restricting overflow to LLC Overflow List A B Further details on supporting overflows are in the paper. C!13
65 Evaluation Atomic Visibility Atomic Durability ATOM Locks Hardware Undo Log LogTM+ATOM HTM (LogTM) Hardware Undo Log DHTM HTM Hardware Redo Log (Log Buffer) System Configuration - We evaluate an 8-core machine with a 2-level cache hierarchy - HTM s implement (first) writer wins conflict resolution policy!14
66 Evaluation!15
67 Evaluation 2 ATOM LogTM+ATOM DHTM queue hash sdg sps btree rbtree gmean!15
68 Evaluation 2 ATOM LogTM+ATOM DHTM queue hash sdg sps btree rbtree gmean!15
69 Evaluation 2 ATOM LogTM+ATOM DHTM queue hash sdg sps btree rbtree gmean!15
70 Evaluation 2 ATOM LogTM+ATOM DHTM % queue hash sdg sps btree rbtree gmean!15
71 Evaluation 2 ATOM LogTM+ATOM DHTM % queue hash sdg sps btree rbtree gmean!15
72 Conclusion Persistent memory systems require crash consistency ACID Transactions: widely understood crash consistency mechanism DHTM: ACID transactions in hardware - Atomic Visibility: commercial HTM - Atomic Durability: bandwidth optimized hardware redo log - Leverage hardware logging to extend transaction size unto LLC!16
73 DHTM: Durable Hardware Transactional Memory Arpit Joshi, Vijay Nagarajan, Marcelo Cintra, Stratis Viglas ISCA 2018
Architectural Support for Atomic Durability in Non-Volatile Memory
Architectural Support for Atomic Durability in Non-Volatile Memory Arpit Joshi, Vijay Nagarajan, Stratis Viglas, Marcelo Cintra NVMW 2018 Summary Non-Volatile Memory (NVM) - on the memory bus enables in-memory
Efficient Persist Barriers for Multicores
fficient Persist Barriers for Multicores Arpit Joshi, Vijay Nagarajan, Marcelo Cintra, Stratis Viglas Summary fficient persist barrier Used to implement persistency models Persistency = when stores become
Blurred Persistence in Transactional Persistent Memory
Blurred Persistence in Transactional Persistent Memory Youyou Lu, Jiwu Shu, Long Sun Tsinghua University Overview Problem: high performance overhead in ensuring storage consistency of persistent memory
Loose-Ordering Consistency for Persistent Memory
Loose-Ordering Consistency for Persistent Memory Youyou Lu 1, Jiwu Shu 1, Long Sun 1, Onur Mutlu 2 1 Tsinghua University 2 Carnegie Mellon University Summary Problem: Strict write ordering required for
LogTM: Log-Based Transactional Memory
LogTM: Log-Based Transactional Memory Kevin E. Moore, Jayaram Bobba, Michelle J. Moravan, Mark D. Hill, & David A. Wood 12th International Symposium on High Performance Computer Architecture () 26 Mulitfacet
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons) Transactions - Definition A transaction is a sequence of data operations with the following properties: * A Atomic All
Lecture 21: Transactional Memory. Topics: Hardware TM basics, different implementations
Lecture 21: Transactional Memory Topics: Hardware TM basics, different implementations 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end locks are blocking,
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons) Goal A Distributed Transaction We want a transaction that involves multiple nodes Review of transactions and their properties
Lecture: Transactional Memory. Topics: TM implementations
Lecture: Transactional Memory Topics: TM implementations 1 Summary of TM Benefits As easy to program as coarse-grain locks Performance similar to fine-grain locks Avoids deadlock 2 Design Space Data Versioning
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons) Transactions - Definition A transaction is a sequence of data operations with the following properties: * A Atomic All
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons)
) Intel)(TX)memory):) Transac'onal) Synchroniza'on) Extensions)(TSX))) Transac'ons) Goal A Distributed Transaction We want a transaction that involves multiple nodes Review of transactions and their properties
Loose-Ordering Consistency for Persistent Memory
Loose-Ordering Consistency for Persistent Memory Youyou Lu, Jiwu Shu, Long Sun and Onur Mutlu Department of Computer Science and Technology, Tsinghua University, Beijing, China State Key Laboratory of
Log-Based Transactional Memory
Log-Based Transactional Memory Kevin E. Moore University of Wisconsin-Madison Motivation Chip-multiprocessors/Multi-core/Many-core are here Intel has 1 projects in the works that contain four or more computing
Lecture 8: Transactional Memory TCC. Topics: lazy implementation (TCC)
Lecture 8: Transactional Memory TCC Topics: lazy implementation (TCC) 1 Other Issues Nesting: when one transaction calls another flat nesting: collapse all nested transactions into one large transaction
SoftWrAP: A Lightweight Framework for Transactional Support of Storage Class Memory
SoftWrAP: A Lightweight Framework for Transactional Support of Storage Class Memory Ellis Giles Rice University Houston, Texas erg@rice.edu Kshitij Doshi Intel Corp. Portland, OR kshitij.a.doshi@intel.com
Database Management System
Database Management System Lecture 10 Recovery * Some materials adapted from R. Ramakrishnan, J. Gehrke and Shawn Bowers Basic Database Architecture Database Management System 2 Recovery Which ACID properties
Lecture 12 Transactional Memory
CSCI-UA.0480-010 Special Topics: Multicore Programming Lecture 12 Transactional Memory Christopher Mitchell, Ph.D. cmitchell@cs.nyu.edu http://z80.me Database Background Databases have successfully exploited
Goldibear and the 3 Locks. Programming With Locks Is Tricky. More Lock Madness. And To Make It Worse. Transactional Memory: The Big Idea
Programming With Locks s Tricky Multicore processors are the way of the foreseeable future thread-level parallelism anointed as parallelism model of choice Just one problem Writing lock-based multi-threaded
Cost of Concurrency in Hybrid Transactional Memory. Trevor Brown (University of Toronto) Srivatsan Ravi (Purdue University)
Cost of Concurrency in Hybrid Transactional Memory Trevor Brown (University of Toronto) Srivatsan Ravi (Purdue University) 1 Transactional Memory: a history Hardware TM Software TM Hybrid TM 1993 1995-today
Logging in Persistent Memory: to Cache, or Not to Cache? Mengjie Li, Matheus Ogleari, Jishen Zhao
Logging in Persistent Memory: to Cache, or Not to Cache? Mengjie Li, Matheus Ogleari, Jishen Zhao Persistent Memory CPU DRAM Disk/Flash Memory Load/store Not persistent Storage Fopen, fread, fwrite, Persistent
Transactions. A Banking Example
Transactions A transaction is specified by a client as a sequence of operations on objects to be performed as an indivisible unit by the servers managing those objects Goal is to ensure that all objects
Lecture 6: TM Eager Implementations. Topics: Eager conflict detection (LogTM), TM pathologies
Lecture 6: TM Eager Implementations Topics: Eager conflict detection (LogTM), TM pathologies 1 Design Space Data Versioning Eager: based on an undo log Lazy: based on a write buffer Typically, versioning
Recoverability. Kathleen Durant PhD CS3200
Recoverability Kathleen Durant PhD CS3200 1 Recovery Manager Recovery manager ensures the ACID principles of atomicity and durability Atomicity: either all actions in a transaction are done or none are
Lecture: Consistency Models, TM. Topics: consistency models, TM intro (Section 5.6)
Lecture: Consistency Models, TM Topics: consistency models, TM intro (Section 5.6) 1 Coherence Vs. Consistency Recall that coherence guarantees (i) that a write will eventually be seen by other processors,
Lowering the Overhead of Nonblocking Software Transactional Memory
Lowering the Overhead of Nonblocking Software Transactional Memory Virendra J. Marathe Michael F. Spear Christopher Heriot Athul Acharya David Eisenstat William N. Scherer III Michael L. Scott Background
Topics. File Buffer Cache for Performance. What to Cache? COS 318: Operating Systems. File Performance and Reliability
Topics COS 318: Operating Systems File Performance and Reliability File buffer cache Disk failure and recovery tools Consistent updates Transactions and logging 2 File Buffer Cache for Performance What
Database Recovery. Haengrae Cho Yeungnam University. Database recovery. Introduction to Database Systems
Database Recovery Haengrae Cho Yeungnam University Database recovery. Introduction to Database Systems Report Yeungnam University, Database Lab. Chapter 1-1 1. Introduction to Database Recovery 2. Recovery
Lecture: Transactional Memory, Networks. Topics: TM implementations, on-chip networks
Lecture: Transactional Memory, Networks Topics: TM implementations, on-chip networks 1 Summary of TM Benefits As easy to program as coarse-grain locks Performance similar to fine-grain locks Avoids deadlock
Lecture 21: Transactional Memory. Topics: consistency model recap, introduction to transactional memory
Lecture 21: Transactional Memory Topics: consistency model recap, introduction to transactional memory 1 Example Programs Initially, A = B = 0 P1 P2 A = 1 B = 1 if (B == 0) if (A == 0) critical section
Hardware Undo+Redo Logging. Matheus Ogleari Ethan Miller Jishen Zhao CRSS Retreat 2018 May 16, 2018
Hardware Undo+Redo Logging Matheus Ogleari Ethan Miller Jishen Zhao https://users.soe.ucsc.edu/~mogleari/ CRSS Retreat 2018 May 16, 2018 Typical Memory and Storage Hierarchy: Memory Fast access to working
Non-Volatile Memory Through Customized Key-Value Stores
Non-Volatile Memory Through Customized Key-Value Stores Leonardo Mármol 1 Jorge Guerra 2 Marcos K. Aguilera 2 1 Florida International University 2 VMware L. Mármol, J. Guerra, M. K. Aguilera (FIU and VMware)
Lecture 4: Directory Protocols and TM. Topics: corner cases in directory protocols, lazy TM
Lecture 4: Directory Protocols and TM Topics: corner cases in directory protocols, lazy TM 1 Handling Reads When the home receives a read request, it looks up memory (speculative read) and directory in
Chí Cao Minh 28 May 2008
Chí Cao Minh 28 May 2008 Uniprocessor systems hitting limits Design complexity overwhelming Power consumption increasing dramatically Instruction-level parallelism exhausted Solution is multiprocessor
TRANSACTION PROCESSING MONITOR OVERVIEW OF TPM FOR DISTRIBUTED TRANSACTION PROCESSING
TPM Transaction Processing TPM Monitor TRANSACTION PROCESSING MONITOR OVERVIEW OF TPM FOR DISTRIBUTED TRANSACTION PROCESSING Peter R. Egli 1/9 Contents 1. What are Transaction Processing Monitors?. Properties
Potential violations of Serializability: Example 1
CSCE 6610:Advanced Computer Architecture Review New Amdahl s law A possible idea for a term project Explore my idea about changing frequency based on serial fraction to maintain fixed energy or keep same
Lecture 7: Transactional Memory Intro. Topics: introduction to transactional memory, lazy implementation
Lecture 7: Transactional Memory Intro Topics: introduction to transactional memory, lazy implementation 1 Transactions New paradigm to simplify programming instead of lock-unlock, use transaction begin-end
Transactional Memory. How to do multiple things at once. Benjamin Engel Transactional Memory 1 / 28
Transactional Memory or How to do multiple things at once Benjamin Engel Transactional Memory 1 / 28 Transactional Memory: Architectural Support for Lock-Free Data Structures M. Herlihy, J. Eliot, and
CSE 530A ACID. Washington University Fall 2013
CSE 530A ACID Washington University Fall 2013 Concurrency Enterprise-scale DBMSs are designed to host multiple databases and handle multiple concurrent connections Transactions are designed to enable Data
Lecture: Consistency Models, TM
Lecture: Consistency Models, TM Topics: consistency models, TM intro (Section 5.6) No class on Monday (please watch TM videos) Wednesday: TM wrap-up, interconnection networks 1 Coherence Vs. Consistency
Making the Fast Case Common and the Uncommon Case Simple in Unbounded Transactional Memory
Making the Fast Case Common and the Uncommon Case Simple in Unbounded Transactional Memory Colin Blundell (University of Pennsylvania) Joe Devietti (University of Pennsylvania) E Christopher Lewis (VMware,
Outline. Purpose of this paper. Purpose of this paper. Transaction Review. Outline. Aries: A Transaction Recovery Method
Outline Aries: A Transaction Recovery Method Presented by Haoran Song Discussion by Hoyt Purpose of this paper Computer system is crashed as easily as other devices. Disk burned Software Errors Fires or
FlexTM. Flexible Decoupled Transactional Memory Support. Arrvindh Shriraman Sandhya Dwarkadas Michael L. Scott Department of Computer Science
FlexTM Flexible Decoupled Transactional Memory Support Arrvindh Shriraman Sandhya Dwarkadas Michael L. Scott Department of Computer Science 1 Transactions: Our Goal Lazy Txs (i.e., optimistic conflict
Lecture 6: Lazy Transactional Memory. Topics: TM semantics and implementation details of lazy TM
Lecture 6: Lazy Transactional Memory Topics: TM semantics and implementation details of lazy TM 1 Transactions Access to shared variables is encapsulated within transactions the system gives the illusion
Transactional Memory. Yaohua Li and Siming Chen. Yaohua Li and Siming Chen Transactional Memory 1 / 41
Transactional Memory Yaohua Li and Siming Chen Yaohua Li and Siming Chen Transactional Memory 1 / 41 Background Processor hits physical limit on transistor density Cannot simply put more transistors to
Berkeley DB Architecture
1-Sep-2013 Table of contents 1 Introduction About Berkeley DB Key Features Presence of Berkeley DB 2 Overview The Access Methods 3 Mpool Lock Log Transaction Recovery About Berkeley DB Key Features Presence
Managing Resource Limitation of Best-Effort HTM
Managing Resource Limitation of Best-Effort HTM Mohamed Mohamedin, Roberto Palmieri, Ahmed Hassan, Binoy Ravindran Abstract The first release of hardware transactional memory (HTM) as commodity processor
Relaxing Persistent Memory Constraints with Hardware-Driven Undo+Redo Logging
Relaxing Persistent Memory Constraints with Hardware-Driven Undo+Redo Logging Matheus A. Ogleari mogleari@ucsc.edu Ethan L. Miller elm@ucsc.edu University of California, Santa Cruz November 19, 2016 Jishen
Database Technology. Topic 8: Introduction to Transaction Processing
Topic 8: Introduction to Transaction Processing Olaf Hartig olaf.hartig@liu.se Motivation A DB is a shared resource accessed by many users and processes concurrently Not managing concurrent access to a
Transactional Memory. Concurrency unlocked Programming. Bingsheng Wang TM Operating Systems
Concurrency unlocked Programming Bingsheng Wang TM Operating Systems 1 Outline Background Motivation Database Transaction Transactional Memory History Transactional Memory Example Mechanisms Software Transactional
Database Technology. Topic 11: Database Recovery
Topic 11: Database Recovery Olaf Hartig olaf.hartig@liu.se Types of Failures Database may become unavailable for use due to: Transaction failures e.g., incorrect input, deadlock, incorrect synchronization
6 Transactional Memory. Robert Mullins
6 Transactional Memory ( MPhil Chip Multiprocessors (ACS Robert Mullins Overview Limitations of lock-based programming Transactional memory Programming with TM ( STM ) Software TM ( HTM ) Hardware TM 2
High Performance Transactions in Deuteronomy
High Performance Transactions in Deuteronomy Justin Levandoski, David Lomet, Sudipta Sengupta, Ryan Stutsman, and Rui Wang Microsoft Research Overview Deuteronomy: componentized DB stack Separates transaction,
Copyright 2016 Ramez Elmasri and Shamkant B. Navathe
CHAPTER 20 Introduction to Transaction Processing Concepts and Theory Introduction Transaction Describes local unit of database processing Transaction processing systems Systems with large databases and
Hardware Transactional Memory on Haswell
Hardware Transactional Memory on Haswell Viktor Leis Technische Universität München 1 / 15 Introduction transactional memory is a very elegant programming model transaction { transaction { a = a 10; c
Recovery System These slides are a modified version of the slides of the book Database System Concepts (Chapter 17), 5th Ed McGraw-Hill by
Recovery System These slides are a modified version of the slides of the book Database System Concepts (Chapter 17), 5th Ed., McGraw-Hill, by Silberschatz, Korth and Sudarshan. Original slides are available
NOTES W2006 CPS610 DBMS II. Prof. Anastase Mastoras. Ryerson University
NOTES W2006 CPS610 DBMS II Prof. Anastase Mastoras Ryerson University Recovery Transaction: - a logical unit of work. (text). It is a collection of operations that performs a single logical function in
Transactions. Transaction. Execution of a user program in a DBMS.
Transactions Transactions Transaction Execution of a user program in a DBMS. Transactions Transaction Execution of a user program in a DBMS. Transaction properties Atomicity: all-or-nothing execution Consistency:
Improving the Practicality of Transactional Memory
Improving the Practicality of Transactional Memory Woongki Baek Electrical Engineering Stanford University Programming Multiprocessors Multiprocessor systems are now everywhere From embedded to datacenter
Databases: transaction processing
Databases: transaction processing P.A.Rounce Room 6.18 p.rounce@cs.ucl.ac.uk 1 ACID Database operation is processing of a set of transactions Required features of a database transaction should be Atomicity
HTM in the wild. Konrad Lai June 2015
HTM in the wild Konrad Lai June 2015 Industrial Considerations for HTM Provide a clear benefit to customers Improve performance & scalability Ease programmability going forward Improve something common
ECE 650 Systems Programming & Engineering. Spring 2018
ECE 650 Systems Programming & Engineering Spring 2018 Database Transaction Processing Tyler Bletsch Duke University Slides are adapted from Brian Rogers (Duke) Transaction Processing Systems Systems with
Chapter 16: Recovery System. Chapter 16: Recovery System
Chapter 16: Recovery System Database System Concepts, 6 th Ed. See www.db-book.com for conditions on re-use Chapter 16: Recovery System Failure Classification Storage Structure Recovery and Atomicity Log-Based
Chapter 17: Recovery System
Chapter 17: Recovery System Database System Concepts See www.db-book.com for conditions on re-use Chapter 17: Recovery System Failure Classification Storage Structure Recovery and Atomicity Log-Based Recovery
Moneta: A High-Performance Storage Architecture for Next-generation, Non-volatile Memories
Moneta: A High-Performance Storage Architecture for Next-generation, Non-volatile Memories Adrian M. Caulfield Arup De, Joel Coburn, Todor I. Mollov, Rajesh K. Gupta, Steven Swanson Non-Volatile Systems
OS Support for Virtualizing Hardware Transactional Memory
OS Support for Virtualizing Hardware Transactional Memory Michael M. Swift, Haris Volos, Luke Yen, Neelam Goyal, Mark D. Hill and David A. Wood University of Wisconsin Madison The Virtualization Problem
Consistency & TM. Consistency
Consistency & TM Today s topics: Consistency models the when of the CC-NUMA game Transactional Memory an alternative to lock based synchronization additional reading: paper from HPCA 26 on class web page
Page 1. Consistency. Consistency & TM. Consider. Enter Consistency Models. For DSM systems. Sequential consistency
Consistency Consistency & TM Today s topics: Consistency models the when of the CC-NUMA game Transactional Memory an alternative to lock based synchronization additional reading: paper from HPCA 26 on
Lecture 10: TM Implementations. Topics: wrap-up of eager implementation (LogTM), scalable lazy implementation
Lecture 10: TM Implementations Topics: wrap-up of eager implementation (LogTM), scalable lazy implementation 1 Eager Overview Topics: Logs Log optimization Conflict examples Handling deadlocks Sticky scenarios
An Analysis of Persistent Memory Use with WHISPER
An Analysis of Persistent Memory Use with WHISPER Sanketh Nalli, Swapnil Haria, Michael M. Swift, Mark D. Hill, Haris Volos*, Kimberly Keeton* University of Wisconsin- Madison & *Hewlett- Packard Labs
An Analysis of Persistent Memory Use with WHISPER
An Analysis of Persistent Memory Use with WHISPER Sanketh Nalli, Swapnil Haria, Michael M. Swift, Mark D. Hill, Haris Volos*, Kimberly Keeton* University of Wisconsin- Madison & *Hewlett- Packard Labs
transaction - (another def) - the execution of a program that accesses or changes the contents of the database
Chapter 19-21 - Transaction Processing Concepts transaction - logical unit of database processing - becomes interesting only with multiprogramming - multiuser database - more than one transaction executing
Synchronization Part 2. REK s adaptation of Claypool s adaptation oftanenbaum s Distributed Systems Chapter 5 and Silberschatz Chapter 17
Synchronization Part 2 REK s adaptation of Claypool s adaptation oftanenbaum s Distributed Systems Chapter 5 and Silberschatz Chapter 17 1 Outline Part 2! Clock Synchronization! Clock Synchronization Algorithms!
Hardware Support for NVM Programming
Hardware Support for NVM Programming 1 Outline Ordering Transactions Write endurance 2 Volatile Memory Ordering Write-back caching Improves performance Reorders writes to DRAM STORE A STORE B CPU CPU B
Foundation of Database Transaction Processing. Copyright 2012 Pearson Education, Inc.
Foundation of Database Transaction Processing Copyright 2012 Pearson Education, Inc. Chapter Outline - 17.1 Introduction to Transaction Processing - 17.2 Transaction and System Concepts - 17.3 Desirable
CSE 444: Database Internals. Section 9: 2-Phase Commit and Replication
CSE 444: Database Internals Section 9: 2-Phase Commit and Replication 1 Today 2-Phase Commit Replication 2 Two-Phase Commit Protocol (2PC) One coordinator and many subordinates Phase 1: Prepare Phase 2:
Lecture 20: Transactional Memory. Parallel Computer Architecture and Programming CMU , Spring 2013
Lecture 20: Transactional Memory Parallel Computer Architecture and Programming Slide credit Many of the slides in today s talk are borrowed from Professor Christos Kozyrakis (Stanford University) Raising
Consistency and Scalability
COMP 150-IDS: Internet Scale Distributed Systems (Spring 2015) Consistency and Scalability Noah Mendelsohn Tufts University Email: noah@cs.tufts.edu Web: http://www.cs.tufts.edu/~noah Copyright 2015 Noah
EazyHTM: Eager-Lazy Hardware Transactional Memory
EazyHTM: Eager-Lazy Hardware Transactional Memory Saša Tomić, Cristian Perfumo, Chinmay Kulkarni, Adrià Armejach, Adrián Cristal, Osman Unsal, Tim Harris, Mateo Valero Barcelona Supercomputing Center,
Introduction to Transaction Processing Concepts and Theory
Chapter 4 Introduction to Transaction Processing Concepts and Theory Adapted from the slides of Fundamentals of Database Systems (Elmasri et al., 2006) 1 Chapter Outline Introduction to Transaction Processing
SQL: Transactions. Introduction to Databases CompSci 316 Fall 2017
SQL: Transactions Introduction to Databases CompSci 316 Fall 2017 2 Announcements (Tue., Oct. 17) Midterm graded Sample solution already posted on Sakai Project Milestone #1 feedback by email this weekend
Portland State University ECE 588/688. Transactional Memory
Portland State University ECE 588/688 Transactional Memory Copyright by Alaa Alameldeen 2018 Issues with Lock Synchronization Priority Inversion A lower-priority thread is preempted while holding a lock
Global atomicity. Such distributed atomicity is called global atomicity A protocol designed to enforce global atomicity is called commit protocol
Global atomicity In distributed systems a set of processes may be taking part in executing a task Their actions may have to be atomic with respect to processes outside of the set example: in a distributed
Transactional Memory. Lecture 19: Parallel Computer Architecture and Programming CMU /15-618, Spring 2015
Lecture 19: Transactional Memory Parallel Computer Architecture and Programming CMU 15-418/15-618, Spring 2015 Credit: many of the slides in today s talk are borrowed from Professor Christos Kozyrakis
MultiJav: A Distributed Shared Memory System Based on Multiple Java Virtual Machines. MultiJav: Introduction
: A Distributed Shared Memory System Based on Multiple Java Virtual Machines X. Chen and V.H. Allan Computer Science Department, Utah State University 1998 : Introduction Built on concurrency supported
RECOVERY CHAPTER 21,23 (6/E) CHAPTER 17,19 (5/E)
RECOVERY CHAPTER 21,23 (6/E) CHAPTER 17,19 (5/E) 2 LECTURE OUTLINE Failures Recoverable schedules Transaction logs Recovery procedure 3 PURPOSE OF DATABASE RECOVERY To bring the database into the most
File Systems: Consistency Issues
File Systems: Consistency Issues File systems maintain many data structures Free list/bit vector Directories File headers and inode structures res Data blocks File Systems: Consistency Issues All data
Distributed Systems
15-440 Distributed Systems 11 - Fault Tolerance, Logging and Recovery Tuesday, Oct 2 nd, 2018 Logistics Updates P1 Part A checkpoint Part A due: Saturday 10/6 (6-week drop deadline 10/8) *Please WORK hard
Computer Science 146. Computer Architecture
Computer Architecture Spring 24 Harvard University Instructor: Prof. dbrooks@eecs.harvard.edu Lecture 2: More Multiprocessors Computation Taxonomy SISD SIMD MISD MIMD ILP Vectors, MM-ISAs Shared Memory
A can be implemented as a separate process to which transactions send lock and unlock requests The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction
Fall 2012 Parallel Computer Architecture Lecture 16: Speculation II. Prof. Onur Mutlu Carnegie Mellon University 10/12/2012
18-742 Fall 2012 Parallel Computer Architecture Lecture 16: Speculation II Prof. Onur Mutlu Carnegie Mellon University 10/12/2012 Past Due: Review Assignments Was Due: Tuesday, October 9, 11:59pm. Sohi
Database Management Systems Reliability Management
Database Management Systems Reliability Management D B M G 1 DBMS Architecture SQL INSTRUCTION OPTIMIZER MANAGEMENT OF ACCESS METHODS CONCURRENCY CONTROL BUFFER MANAGER RELIABILITY MANAGEMENT Index Files
Recovery System These slides are a modified version of the slides of the book Database System Concepts (Chapter 17), 5th Ed
Recovery System These slides are a modified version of the slides of the book Database System Concepts (Chapter 17), 5th Ed., McGraw-Hill, by Silberschatz, Korth and Sudarshan. Original slides are available
FAULT TOLERANT SYSTEMS
FAULT TOLERANT SYSTEMS http://www.ecs.umass.edu/ece/koren/faulttolerantsystems Part 18 Chapter 7 Case Studies Part.18.1 Introduction Illustrate practical use of methods described previously Highlight fault-tolerance
Invyswell: A HyTM for Haswell RTM. Irina Calciu, Justin Gottschlich, Tatiana Shpeisman, Gilles Pokam, Maurice Herlihy
Invyswell: A HyTM for Haswell RTM Irina Calciu, Justin Gottschlich, Tatiana Shpeisman, Gilles Pokam, Maurice Herlihy Multicore Performance Scaling u Problem: Locking u Solution: HTM? u IBM BG/Q, zec12,
McRT-STM: A High Performance Software Transactional Memory System for a Multi- Core Runtime
McRT-STM: A High Performance Software Transactional Memory System for a Multi- Core Runtime B. Saha, A-R. Adl- Tabatabai, R. Hudson, C.C. Minh, B. Hertzberg PPoPP 2006 Introductory TM Sales Pitch Two legs
COURSE 1. Database Management Systems
COURSE 1 Database Management Systems Assessment / Other Details Final grade 50% - laboratory activity / practical test 50% - written exam Course details (bibliography, course slides, seminars, lab descriptions
Shared Memory Multiprocessors. Symmetric Shared Memory Architecture (SMP) Cache Coherence. Cache Coherence Mechanism. Interconnection Network
Shared Memory Multis Processor Processor Processor i Processor n Symmetric Shared Memory Architecture (SMP) cache cache cache cache Interconnection Network Main Memory I/O System Cache Coherence Cache
Goal A Distributed Transaction
Goal A Distributed Transaction We want a transaction that involves multiple nodes Review of transactions and their properties Things we need to implement transactions * Locks * Achieving atomicity through
New Abstractions for Fast Non-Volatile Storage
New Abstractions for Fast Non-Volatile Storage Joel Coburn, Adrian Caulfield, Laura Grupp, Ameen Akel, Steven Swanson Non-volatile Systems Laboratory Department of Computer Science and Engineering University
Lecture 8: Eager Transactional Memory. Topics: implementation details of eager TM, various TM pathologies
Lecture 8: Eager Transactional Memory Topics: implementation details of eager TM, various TM pathologies 1 Eager Overview Topics: Logs Log optimization Conflict examples Handling deadlocks Sticky scenarios