pClock

Abstract

Storage consolidation is becoming an attractive paradigm for data organization because of the economies of sharing and the ease of centralized management. However, sharing of resources is viable only if applications can be isolated from each other. This work targets the problem of providing performance guarantees to an application irrespective of the behavior of other workloads. Application requirements are represented in terms of the average throughput, latency and maximum burst size. Most earlier schemes only do weighted bandwidth allocation; schemes that provide control of latency either cannot handle bursts or penalize applications for their own prior behavior, such as using spare capacity.Our algorithm pClock is based on arrival curves that intuitively capture the bandwidth and burst requirements of applications. We show analytically that an application following its arrival curve never misses its deadline. We have implemented pClock both in DiskSim [2] and as a module in the Linux kernel 2.6. Our evaluation shows three important features of pClock: (1) benefits over existing algorithms; (2) efficient performance isolation and burst handling; and (3) the ability to allocate spare capacity to either speed up some applications or to a background utility, such as backup. pClock can be efficiently implemented in a system without much overhead.

Malleability in Modern HPC Systems: Current Experiences, Challenges, and Future Opportunities

“…Further control of application impact on I/O can be achieved with QoS extensions for PFSs [92], [93], such as the token bucket filter in the Lustre file system's network request scheduler [94]. This can limit the number of data and metadata requests to prevent a single application from saturating the storage.…”

Damaris

“…QoS-based scheduling is used in particular in enterprise storage systems [Gulati et al 2007;Wachs et al 2007] and in the field of cloud computing [Pu et al 2010], where pricing models require performance guaranties. It generally involves isolation techniques and bandwidth allocation to ensure that an application's I/O performance is guaranteed.…”

PriorityMeister

“…Of the ones that focus on latency, most of them target the average latency [8,12,15,16]. We are only aware of two storage schedulers, Cake [21] and Avatar [25], that investigate tail latency behavior.…”

“…Sharing bandwidth is easier than latency QoS because bandwidth is an average over time that is not affected by transient queueing. Some prior work targets latency QoS, but most of this work is focused on the average latency [8,12,15,16]. Looking at the average can mask some of the worst-case behaviors that often lead to stragglers.…”

“…First, we develop an algorithm for automatically determining the priority and rate limits for each of the workloads at each stage to meet end-to-end latency SLOs. PriorityMeister achieves these goals by combining network calculus with the Scheduler Latency SLO Multi-resource Argon [20] No No SFQ(D) [11] No No AQuA [22] No No mClock [10] No No PARDA [9] No Yes PISCES [18] No Yes Maestro [16] Average latency No Triage [12] Average latency No Façade [15] Average latency No pClock [8] Average latency No Avatar [25] 95th percentile No Cake [21] 99th percentile Yes PriorityMeister > 99th percentile Yes Table 1. Comparison of storage schedulers.…”