CS510 Concurrent Systems “What is RCU, Fundamentally?” By Paul McKenney and Jonathan Walpole Daniel Mansour (Slides adapted from Professor Walpole’s)

Slides:



Advertisements
Similar presentations
Linked Lists in C and C++ CS-2303, C-Term Linked Lists in C and C++ CS-2303 System Programming Concepts (Slides include materials from The C Programming.
Advertisements

CS 11 C track: lecture 7 Last week: structs, typedef, linked lists This week: hash tables more on the C preprocessor extern const.
Data Structure Lecture-5
Module R2 CS450. Next Week R1 is due next Friday ▫Bring manuals in a binder - make sure to have a cover page with group number, module, and date. You.
Chapter 17 Linked List Saurav Karmakar Spring 2007.
CS510 Concurrent Systems Jonathan Walpole. What is RCU, Fundamentally? Paul McKenney and Jonathan Walpole.
RCU in the Linux Kernel: One Decade Later by: Paul E. Mckenney, Silas Boyd-Wickizer, Jonathan Walpole Slides by David Kennedy (and sources)
CS 6560 Operating System Design Lecture 7: Kernel Synchronization Kernel Time Management.
Read-Copy Update P. E. McKenney, J. Appavoo, A. Kleen, O. Krieger, R. Russell, D. Saram, M. Soni Ottawa Linux Symposium 2001 Presented by Bogdan Simion.
By Sarita Adve & Kourosh Gharachorloo Review by Jim Larson Shared Memory Consistency Models: A Tutorial.
CS 206 Introduction to Computer Science II 09 / 17 / 2008 Instructor: Michael Eckmann.
What is RCU, fundamentally? Sri Ramkrishna. Intro RCU stands for Read Copy Update  A synchronization method that allows reads to occur concurrently with.
CS510 Concurrent Systems Class 13 Software Transactional Memory Should Not be Obstruction-Free.
Data Structures Topic #3. Today’s Agenda Ordered List ADTs –What are they –Discuss two different interpretations of an “ordered list” –Are manipulated.
CS533 - Concepts of Operating Systems 1 CS533 Concepts of Operating Systems Class 8 Synchronization on Multiprocessors.
CS510 Concurrent Systems Class 5 Threads Cannot Be Implemented As a Library.
Practical Concerns for Scalable Synchronization Jonathan Walpole (PSU) Paul McKenney (IBM) Tom Hart (University of Toronto)
Data Structures in the Kernel Sarah Diesburg COP 5641.
I/O Systems ◦ Operating Systems ◦ CS550. Note:  Based on Operating Systems Concepts by Silberschatz, Galvin, and Gagne  Strongly recommended to read.
CS 241 Section Week #4 (2/19/09). Topics This Section  SMP2 Review  SMP3 Forward  Semaphores  Problems  Recap of Classical Synchronization Problems.
Data Structures Week 5 Further Data Structures The story so far  We understand the notion of an abstract data type.  Saw some fundamental operations.
Introduction to Processes CS Intoduction to Operating Systems.
Cosc 4740 Chapter 6, Part 3 Process Synchronization.
Multiprogramming. Readings r Silberschatz, Galvin, Gagne, “Operating System Concepts”, 8 th edition: Chapter 3.1, 3.2.
CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Synchronization.
By Sarita Adve & Kourosh Gharachorloo Slides by Jim Larson Shared Memory Consistency Models: A Tutorial.
Kernel Locking Techniques by Robert Love presented by Scott Price.
Non-Blocking Concurrent Data Objects With Abstract Concurrency By Jack Pribble Based on, “A Methodology for Implementing Highly Concurrent Data Objects,”
Java Thread and Memory Model
Operating Systems CSE 411 CPU Management Sept Lecture 10 Instructor: Bhuvan Urgaonkar.
The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with Linux Guniguntala et al.
CS510 Concurrent Systems Jonathan Walpole. A Methodology for Implementing Highly Concurrent Data Objects.
CS510 Concurrent Systems Jonathan Walpole. RCU Usage in Linux.
CS533 Concepts of Operating Systems Jonathan Walpole.
CS533 Concepts of Operating Systems Jonathan Walpole.
1 Read-Copy Update Paul E. McKenney Linux Technology Center IBM Beaverton Jonathan Appavoo Department.
Read-Log-Update A Lightweight Synchronization Mechanism for Concurrent Programming Alexander Matveev (MIT) Nir Shavit (MIT and TAU) Pascal Felber (UNINE)
Kernel Structure and Infrastructure David Ferry, Chris Gill CSE 522S - Advanced Operating Systems Washington University in St. Louis St. Louis, MO
CSC 660: Advanced Operating SystemsSlide #1 CSC 660: Advanced OS Synchronization.
1 Critical Section Problem CIS 450 Winter 2003 Professor Jinhua Guo.
CS32 Discussion Section 1B Week 3 TA: Hao Yu (Cody)
Read-Copy-Update Synchronization in the Linux Kernel 1 David Ferry, Chris Gill CSE 522S - Advanced Operating Systems Washington University in St. Louis.
Lists List Implementations. 2 Linked List Review Recall from CMSC 201 –“A linked list is a linear collection of self- referential structures, called nodes,
CMSC 202 Computer Science II for Majors. CMSC 202UMBC Topics Templates Linked Lists.
List Structures What is a list? A homogeneous collection of elements with a linear relationship between the elements linear relationship - each element.
Kernel Synchronization David Ferry, Chris Gill CSE 522S - Advanced Operating Systems Washington University in St. Louis St. Louis, MO
By Michael Greenwald and David Cheriton Presented by Jonathan Walpole
Doubly Linked List Review - We are writing this code
Linked List Variations
Linked Lists head One downside of arrays is that they have a fixed size. To solve this problem of fixed size, we’ll relax the constraint that the.
Doubly linked lists.
LINKED LISTS CSCD Linked Lists.
Object Oriented Programming COP3330 / CGS5409
Kernel Synchronization II
Practical Concerns for Scalable Synchronization
Further Data Structures
Kernel Structure and Infrastructure
Doubly Linked Lists Lecture 21 Tue, Mar 21, 2006.
Linked Lists in C and C++
Software Transactional Memory Should Not be Obstruction-Free
Kernel Synchronization I
CS510 Concurrent Systems Jonathan Walpole.
Kernel Synchronization II
Chapter 3: Processes.
Linked Lists.
Outline Chapter 2 (cont) Chapter 3: Processes Virtual machines
Chapter 3: Process Concept
CSE 451 Section 1/27/2000.
MV-RLU: Scaling Read-Log-Update with Multi-Versioning
Honnappa Nagarahalli Arm
Presentation transcript:

CS510 Concurrent Systems “What is RCU, Fundamentally?” By Paul McKenney and Jonathan Walpole Daniel Mansour (Slides adapted from Professor Walpole’s)

2 Review of Concurrency  The Story So Far o Critical Sections Shared global objects Blocking/Non-Blocking o Reader/Writers Reads are “safer” Writes are Fewer o Hardware/Compiler Optimizations Operations are not always in order o Memory Reclamation Deleted Objects can still be read

3 Read-Copy Update (RCU)  Read/Writes o Do not allow reads while writes are occurring o RCU solves this by allowing multiple versions  Insertion o Publish-Subscribe Mechanism  Deletion o Wait for Readers to complete o Non-Blocking

4 Publish-Subscribe Mechanism 1 struct foo { 2 int a; 3 int b; 4 int c; 5 }; 6 struct foo *gp = NULL; 7 8 /*... */ 9 10 p = kmalloc(sizeof(*p), GFP_KERNEL); 11 p->a = 1; 12 p->b = 2; 13 p->c = 3; 14 gp = p;

5 Publish-Subscribe Mechanism 1 struct foo { 2 int a; 3 int b; 4 int c; 5 }; 6 struct foo *gp = NULL; 7 8 /*... */ 9 10 p = kmalloc(sizeof(*p), GFP_KERNEL); 11 gp = p; 12 p->a = 1; 13 p->b = 2; 14 p->c = 3; Reordered, concurrent readers would get uninitialized values

6 Publish-Subscribe Mechanism  Publish the Object o rcu_assign_pointer 1 p->a = 1; 2 p->b = 2; 3 p->c = 3; 4 rcu_assign_pointer(gp, p);

7 Publish-Subscribe Mechanism  Readers o Ordering can still be an issue o p->a can be read before p in some compiler optimizations 1 p = gp; 2 if (p != NULL) { 3 do_something_with(p->a, p->b, p-c); 4 }

8 Publish-Subscribe Mechanism  Subscribe to the object o rcu_dereference o Implements any necessary memory barriers 1 rcu_read_lock() 2 p = rcu_dereference(gp) 3 if (p != NULL { 4 do_something_with(p->a, p->b, p->c); 5 } 6 rcu_read_unlock();

9 Implementation  Doubly Linked Lists o list_head o Head links to tail with prev and vice versa

10 Implementation - list_head  Publishing 1 struct foo { 2 struct list_head list; 3 int a; 4 int b; 5 int c; 6 }; 7 LIST_HEAD(head); 8 9 /*... */ p = kmalloc(sizeof(*p), GFP_KERNEL); 12 p->a = 1; 13 p->b = 2; 14 p->c = 3; 15 list_add_rcu(&p->list, &head); Still needs to be protected

11 Implementation - list_head  Subscribing 1 rcu_read_lock(); 2 list_for_each_entry_rcu(p, head, list) { 3 do_something_with(p->a, p->b, p->c); 4 } 5 rcu_read_unlock();

12 Implementation - hlist_head/hlist_node  Doubly Linked Lists o hlist_head/hlist_node o Linear list

13 Implementation - hlist_head/hlist_node  Publishing 1 struct foo { 2 struct hlist_node *list; 3 int a; 4 int b; 5 int c; 6 }; 7 HLIST_HEAD(head); 8 9 /*... */ p = kmalloc(sizeof(*p), GFP_KERNEL); 12 p->a = 1; 13 p->b = 2; 14 p->c = 3; 15 hlist_add_head_rcu(&p->list, &head);

14 Implementation - list_head  Subscribing 1 rcu_read_lock(); 2 hlist_for_each_entry_rcu(p, q, head, list) { 3 do_something_with(p->a, p->b, p->c); 4 } 5 rcu_read_unlock(); Iteration requires checking for null Instead of p = head

15 Reclaiming Memory  Waiting o rcu_read_lock and rcu_read_unlock Must not block or sleep

Reclaiming Memory  Basic Process 1. Alter the data (replace/delete an element) 2. Wait for all pre-existing RCU reads to completely finish synchronize_rcu New RCU reads have no way to access removed element 3. Reclaim/Recycle memory 16

Reclaiming Memory  Example 17 1 struct foo { 2 struct list_head list; 3 int a; 4 int b; 5 int c; 6 }; 7 LIST_HEAD(head); 8 9 /*... */ p = search(head, key); 12 if (p == NULL) { 13 /* Take appropriate action, unlock, and return. */ 14 } 15 q = kmalloc(sizeof(*p), GFP_KERNEL); 16 *q = *p; 17 q->b = 2; 18 q->c = 3; 19 list_replace_rcu(&p->list, &q->list); 20 synchronize_rcu(); 21 kfree(p);

Reclaiming Memory  synchronize_rcu o rcu_read_lock and rcu_read_unlock do nothing on non- CONFIG-PREEMPT kernels o Recall that code in rcu_read blocks can not sleep or block, preventing context switches o When a context switch occurs, we can deduce that the read has completed o synchronize_rcu waits for each cpu to context switch conceptually: 18 1 for_each_online_cpu(cpu) 2 run_on(cpu);

Maintaining Multiple Versions - Deletion  During deletion  Initial State 19 1 p = search(head, key); 2 if (p != NULL) { 3 list_del_rcu(&p->list); 4 synchronize_rcu(); 5 kfree(p); 6 }

Maintaining Multiple Versions - Deletion  list_del_rcu(&p->list)  p has been deleted, but other readers can still be accessing it 20

Maintaining Multiple Versions - Deletion  synchronize_rcu()  kfree(p) 21

Maintaining Multiple Versions - Replacement  During replacement  Initial State 22 1 q = kmalloc(sizeof(*p), GFP_KERNEL); 2 *q = *p; 3 q->b = 2; 4 q->c = 3; 5 list_replace_rcu(&p->list, &q->list); 6 synchronize_rcu(); 7 kfree(p);

Maintaining Multiple Versions - Replacement  kmalloc() 23

Maintaining Multiple Versions - Replacement  *q = *p 24

Maintaining Multiple Versions - Replacement  q->b = 2; q->c = 3 25

Maintaining Multiple Versions - Replacement  list_replace_rcu  There are now two versions of the list, but both are well formed. 26

Maintaining Multiple Versions - Replacement  synchronize_rcu  kfree() 27

Issues  Very much a read/write implementation, not ideally suited for rapidly updated objects  Responsibility on the programmer to make sure that no sleeping/blocking occurs in rcu_read_locks  RCU updaters can still slow readers via cache invalidation 28