RadixVM

Clements, Austin T.; Kaashoek, M. Frans; Zeldovich, Nickolai

doi:10.1145/2465351.2465373

Cited by 62 publications

(8 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similarly, from opt nodes to max nodes, the request execution time increases 3.4× and the tail latency increases 21.0×. The experiments with a single thread for all the studied applications except MySQL and SQLite 23 are available in the Appendix ( §D). Overall, we found that, on the studied applications with a single-threaded configuration, the choice of a lock has very little effect on the throughput or the tail latency of the application.…”

Section: How Does Tail Latency Behave When Locks Suffer From High Levels Of Contention?mentioning

confidence: 99%

Lock–Unlock

Guerraoui

Guiroux

Lachaize

et al. 2018

ACM Trans. Comput. Syst.

View full text Add to dashboard Cite

A plethora of optimized mutex lock algorithms have been designed over the past 25 years to mitigate performance bottlenecks related to critical sections and locks. Unfortunately, there is currently no broad study of the behavior of these optimized lock algorithms on realistic applications that consider different performance metrics, such as energy efficiency and tail latency. In this article, we perform a thorough and practical analysis of synchronization, with the goal of providing software developers with enough information to design fast, scalable, and energy-efficient synchronization in their systems. First, we perform a performance study of 28 state-of-the-art mutex lock algorithms, on 40 applications, on four different multicore machines. We consider not only throughput (traditionally the main performance metric) but also energy efficiency and tail latency, which are becoming increasingly important. Second, we present an in-depth analysis in which we summarize our findings for all the studied applications. In particular, we describe nine different lock-related performance bottlenecks, and we propose six guidelines helping software developers with their choice of a lock algorithm according to the different lock properties and the application characteristics. From our detailed analysis, we make several observations regarding locking algorithms and application behaviors, several of which have not been previously discovered: (i) applications stress not only the lock–unlock interface but also the full locking API (e.g., trylocks, condition variables); (ii) the memory footprint of a lock can directly affect the application performance; (iii) for many applications, the interaction between locks and scheduling is an important application performance factor; (vi) lock tail latencies may or may not affect application tail latency; (v) no single lock is systematically the best; (vi) choosing the best lock is difficult; and (vii) energy efficiency and throughput go hand in hand in the context of lock algorithms. These findings highlight that locking involves more considerations than the simple lock/unlock interface and call for further research on designing low-memory footprint adaptive locks that fully and efficiently support the full lock interface, and consider all performance metrics.

show abstract

Section: How Does Tail Latency Behave When Locks Suffer From High Levels Of Contention?mentioning

confidence: 99%

Lock–Unlock

Guerraoui

Guiroux

Lachaize

et al. 2018

ACM Trans. Comput. Syst.

View full text Add to dashboard Cite

show abstract

“…Moreover, mapping virtual memory in a scalable fashion, e.g. as in RadixVM [6], does not solve the problem of designing a competitive allocator. Memory fragmentation and systemcall overhead still need to be managed.…”

Section: Related Workmentioning

confidence: 99%

“…Note that recent Linux kernels provide the ability to use transparent huge pages 6 as backing store for regular pages, i.e., huge pages can be used by the kernel as physical page frames for regular pages. Since this feature interferes with any mechanism relying on on-demand paging, e.g.…”

Section: Experimental Evaluationmentioning

confidence: 99%

“…We still report the 40 threads ticks to illustrate this behavior. 6 See https://www.kernel.org/doc/Documentation/vm/transhuge.txt We compare different allocators on the 483.xalancbmk workload of the SPEC CPU2006 suite which is known to be an allocation intense single-threaded workload [28]. Figure 5 reports a benchmark score called ratio where a higher ratio means a lower benchmark running time.…”

Section: Experimental Evaluationmentioning

confidence: 99%

“…However, even in the presence of 40 threads we do not observe contention on the span-pool. For objects larger than 1MB scalloc relies on mmap which adds system call latency to allocation and deallocation operations and is also known to be a scalability bottleneck [6].…”

Section: Robustness For Varying Object Sizesmentioning

confidence: 99%

See 2 more Smart Citations

Fast, multicore-scalable, low-fragmentation memory allocation through large virtual memory and global data structures

et al. 2015

View full text Add to dashboard Cite

We demonstrate that general-purpose memory allocation involving many threads on many cores can be done with high performance, multicore scalability, and low memory consumption. For this purpose, we have designed and implemented scalloc, a concurrent allocator that generally performs and scales in our experiments better than other allocators while using less memory, and is still competitive otherwise. The main ideas behind the design of scalloc are: uniform treatment of small and big objects through so-called virtual spans, efficiently and effectively reclaiming free memory through fast and scalable global data structures, and constant-time (modulo synchronization) allocation and deallocation operations that trade off memory reuse and spatial locality without being subject to false sharing.

show abstract

Sharing non‐cache‐coherent memory with bounded incoherence

Ren

Parmer

Milojičić

2021

Concurrency and Computation

View full text Add to dashboard Cite

Summary Cache coherence in modern computer architectures enables easier programming by sharing data across multiple processors. Unfortunately, it can also limit scalability due to cache coherency traffic initiated by competing memory accesses. Rack‐scale systems introduce shared memory across a whole rack, but without inter‐node cache coherence. This poses memory management and concurrency control challenges for applications that must explicitly manage cache‐lines. To fully utilize rack‐scale systems for low‐latency and scalable computation, applications need to maintain cached memory accesses in spite of non‐coherency. This paper introduces Bounded Incoherence, a memory consistency model that enables cached access to shared data‐structures in non‐cache‐coherency memory. It ensures that updates to memory on one node are visible within at most a bounded amount of time on all other nodes. We evaluate this memory model on modified PowerGraph graph processing framework, and boost its performance by 30% with eight sockets by enabling cached‐access to data‐structures.

show abstract

RadixVM

Cited by 62 publications

References 22 publications

Lock–Unlock

Lock–Unlock

Fast, multicore-scalable, low-fragmentation memory allocation through large virtual memory and global data structures

Sharing non‐cache‐coherent memory with bounded incoherence

Contact Info

Product

Resources

About