Clearing the clouds

Ferdman, Michael; Adileh, Almutaz; Kocberber, Onur; Volos, Stavros; Alisafaee, Mohammad; Jevdjic, Djordje; Kaynak, Cansu; Popescu, Adrian; Ailamaki, Anastasia; Falsafi, Babak

doi:10.1145/2150976.2150982

Cited by 644 publications

(83 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since simulating virtual machines on QEMU is not feasible as of writing this paper, we mimic page sharing cases by running two instances of the Apache Spark application, collaborative filtering (ALS) [12], on a QEMU virtual machine. Although it cannot simulate the sharing case for operating systems and data segments, it is still possible to share code segments for applications.…”

Section: Discussionmentioning

confidence: 99%

Deduplicating TLB entries for shared pages

Ahn

2018

IEICE Electron. Express

View full text Add to dashboard Cite

Although the page sharing among different address spaces can effectively reduce the memory footprint, the corresponding address mappings still require their own TLB entries. Consequently, redundant address mappings for the shared pages reside in TLBs. Our goal in this study is to increase the TLB density by deduplicating redundant copies of address mappings into a single mapping. In virtualized servers, the case of hosting the same guest operating systems, the same third-party libraries, and the same application is commonly found. Such environments generate the multiple identical address mappings, virtual to physical address, for shared pages among different virtual machines. We exploit this unique characteristic of the virtual memory layout being analogous in the same execution environment, and explore TLB deduplication, called DeTLB, which merges redundant virtual to physical address mappings of different address spaces into a single TLB entry. To demonstrate the performance impact, we develop a QEMU based trace simulator and evaluate the number of TLB misses by running an Apache Spark ALS and a microbenchmark with the Linux KSM module. The results indicate that DeTLB can effectively reduce the number of TLB misses for both data and instructions.

show abstract

Section: Discussionmentioning

confidence: 99%

Deduplicating TLB entries for shared pages

Ahn

2018

IEICE Electron. Express

View full text Add to dashboard Cite

show abstract

“…We run clients on the same machine as the memcached server to remove any network effects. The client and dataset are from cloudsuite [13], with a scaling factor of 10×. We use the number of workers and connections that produces the highest throughput.…”

Section: Extrapolating To Different Machinesmentioning

confidence: 99%

Estima

Chatzopoulos

Dragojević

Guerraoui

2017

ACM Trans. Parallel Comput.

View full text Add to dashboard Cite

This article presents estima, an easy-to-use tool for extrapolating the scalability of in-memory applications. estima is designed to perform a simple yet important task: Given the performance of an application on a small machine with a handful of cores, estima extrapolates its scalability to a larger machine with more cores, while requiring minimum input from the user. The key idea underlying estima is the use of stalled cycles (e.g., cycles that the processor spends waiting for missed cache line fetches or busy locks). estima measures stalled cycles on a few cores and extrapolates them to more cores, estimating the amount of waiting in the system. estima can be effectively used to predict the scalability of in-memory applications for bigger execution machines. For instance, using measurements of memcached and SQLite on a desktop machine, we obtain accurate predictions of their scalability on a server. Our extensive evaluation shows the effectiveness of estima on a large number of in-memory benchmarks. INTRODUCTIONCommodity machines nowadays have hundreds of gigabytes of memory. This enables building performance-critical parallel applications, such as databases and key-value stores, that keep their datasets in main memory. This way, applications avoid slow secondary storage and networks, leaving the CPU as the main performance bottleneck [9,12,26,30]. Understanding the performance of these applications proves to be hard, since the number of CPU cores available during the deployment of a parallel application can be significantly higher than that during its development and testing. Applications developed today can be tested on machines with 16 or 24 cores, but in a few years the same applications are likely to be run on machines with 64 or even more cores.

show abstract

“…We are finalizing our implementation to evaluate Rainbow with VMs running representative cloud workloads [3]. Figure 2 plots a preliminary validation with the PARSEC 2.1 benchmark suite [1].…”

Section: Work In Progressmentioning

confidence: 99%

Coloring the cloud for predictable performance

Scolari

Sironi

Bartolini

et al. 2013

Proceedings of the 4th Annual Symposium on Cloud Computing

View full text Add to dashboard Cite

Motivation and ContributionThe commodity multicores that power cloud infrastructures hide memory latency through deep memory hierarchies, with the lastlevel cache (LLC) usually shared among cores. While a shared LLC improves utilization of on-chip resources, it may also lead to unpredictable performance of colocated virtual machines (VMs) as a result of unanticipated contention. Past research showed that the operating system page allocator can favor performance predictability on a physically-addressed shared LLC through page coloring [4,8,9]: a software technique that can work on commodity multicores, unlike hardware approaches [2,7]. The main drawback of page coloring is the high cost of modifying allocations (i.e., recoloring), making this technique almost impractical for applications with varying memory footprints [6].We aim at finding the simplest technique applicable to commodity multicores to avoid unpredictable performance of co-located VMs. Since VMs have a bounded memory footprint (i.e., stated at deployment time), we can leverage page coloring and avoid the cost of recoloring. We designed and implemented Rainbow: a page allocator exploiting page coloring to expose a new VM configuration knob: cache allocation, which implicitly determines proportional memory allocation. This knob provides users with predictable performance and clouds with a safe way of co-locating VMs.

show abstract

Clearing the clouds

Cited by 644 publications

References 27 publications

Deduplicating TLB entries for shared pages

Deduplicating TLB entries for shared pages

Estima

Coloring the cloud for predictable performance

Contact Info

Product

Resources

About