Prudent Memory Reclamation in Procrastination-Based Synchronization

Size: px

Start display at page:

Download "Prudent Memory Reclamation in Procrastination-Based Synchronization"

Branden Trevor Lane
5 years ago
Views:

Science & Automation (CSA), Indian Institute of Science

1 rudent Memory eclamation in rocrastination-based Synchronization Aravinda rasad & K Gopinath Computer Science & Automation (CSA), Indian Institute of Science (IISc), Bangalore {aravinda, gopi}@csa.iisc.ernet.in EECS

2 2 Synchronization via rocrastination eaders: Do not synchronize with writers Are wait free and scale linearly Writers: Copy the object and update the copied version Wait for pre-existing readers referring the old version to complete Time - Allocate Q Copy and Update Q Q Q Q Defer Free Grace eriod Example: ead-copy-update (CU) Q

3 2 Synchronization via rocrastination eaders: Do not synchronize with writers Are wait free and scale linearly Writers: Copy the object and update the copied version Wait for pre-existing readers referring the old version to complete Time - Allocate Q Copy and Update Q Q Q Q Defer Free Grace eriod Example: ead-copy-update (CU) Q A deferred object is safe for freeing after the completion of all pre-existing readers

4 3 Synchronization via rocrastination from Memory Allocator s oint of View Frequent allocation and freeing of objects Object allocation is spread over an interval of time. Freeing occurs in bursts eclamation of safe deferred objects is Controlled by synchronization mechanism Oblivious of the memory allocator state

5 Impact of CU on the SLUB 1 allocator in the Linux kernel 300 out-of-memory Total Used Memory (GBytes) Time (Seconds) Test Setup: Intel Xeon processor with 64 CUs (4 sockets, 8 cores/socket, 2-way HT) 252 GB physical memory. Linux 3.17 kernel. Workload continuously performs update operation on 512 byte objects 1 SLUB is the recent allocator in the Linux kernel based on the slab allocator 4

6 5 Hints about the future Deferred frees provide precise hints about the memory regions that are about to be freed Grace eriod Update Free Time Hint

7 5 Hints about the future Deferred frees provide precise hints about the memory regions that are about to be freed Grace eriod Update Free Time Hint Given hints about the future, can dynamic memory allocators perform better?

8 6 The rudence Dynamic Memory Allocator The basic design principle is to have deferred objects visible and processed in the memory allocator

9 6 The rudence Dynamic Memory Allocator The basic design principle is to have deferred objects visible and processed in the memory allocator equirement Interface to defer the freeing of an object Identify safe time to reclaim deferred objects Solution Export a new AI to defer free an object (free deferred()) Integrate synchronization mechanism with rudence

10 7 Exploiting hints in rudence educing total fragmentation with hints Total fragmentation = allocated requested = slabs allocated slab size objects requested object size... Slab A free allocated... Slab B (a) Without Hints

11 7 Exploiting hints in rudence educing total fragmentation with hints Total fragmentation = allocated requested = slabs allocated slab size objects requested object size Slab A Slab A free allocated deferred object... Slab B... Slab B (a) Without Hints rudence selects slab A (b) With Hints

12 8 esults - Endurance Total Used Memory (GBytes) SLUB rudence out-of-memory Time (Seconds) rudence does not suffer from high slab churns

13 9 Summary Synchronization via procrastination has direct impact on the performance of memory allocators erformance impact can be avoided by having deferred objects visible to memory allocators Deferred frees provide hints about the memory regions that are about to be freed Optimizations based on hints can be exploited to improve the performance of memory allocators

14 10 Questions? eference: rudent Memory eclamation in rocrastination-based Synchronization, Aravinda rasad, K Gopinath, ASLOS 2016

15 Thank you!! 11

The RCU-Reader Preemption Problem in VMs

The RCU-Reader Preemption Problem in VMs Aravinda Prasad1, K Gopinath1, Paul E. McKenney2 1 2 Indian Institute of Science (IISc), Bangalore IBM Linux Technology Center, Beaverton 2017 USENIX Annual Technical