Improving application responsiveness with the BFQ disk I/O scheduler

Valente, Paolo; Andreolini, Mauro

doi:10.1145/2367589.2367590

Cited by 9 publications

(20 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…While SLASSD [7] uses an opportunistic goal oriented block I/O scheduling algorithm, Kim et al [2] proposes host level SSD I/O schedulers, which are extensions of state-of-the-art I/O scheduling scheme CFQ. ParDispatcher [49] tries to utilize the parallelism in SSDs, by dividing the entire SSD into sub-regions, each having [6] , SLASSD [7], Axboe [44], Hystor [34], PDC [43], ParDispatcher [49], BFQ [50], FlexDrive [12], AD [28], Borg [8] ADLAM [33], SUORA [4], hatS [21], PDC [43], HRO [45], RPAC [46], RAF [47], PASS [48], Triple-H [11], ExaPlan [20], HybridStore [51], Hystor [34], Scarlett [52], DUX [1] a different queue for dispatching requests. ParDipatcher might be good in applications which have more random I/Os otherwise, leading to increasing wait queues for popular sub-regions and bias in performance.…”

Section: Block Layer Developments Mostly I/o Schedulingmentioning

confidence: 99%

Host managed contention avoidance storage solutions for Big Data

Mishra

Somani

2017

J Big Data

View full text Add to dashboard Cite

The performance gap between compute and storage is fairly considerable. This results in a mismatch between the application needs from storage and what storage can deliver. The full potential of storage devices cannot be harnessed till all layers of I/O hierarchy function efficiently. Despite advanced optimizations applied across various layers along the odyssey of data access, the I/O stack still remains volatile. The problems associated due to the inefficiencies in data management get amplified in Big Data shared resource environments. The Linux OS (host) block layer is the most critical part of the I/O hierarchy, as it orchestrates the I/O requests from different applications to the underlying storage. Unfortunately, despite it's significance, the block layer, essentially the block I/O scheduler, hasn't evolved to meet the needs of Big Data. We have designed and developed two contention avoidance storage solutions, collectively known as "BID: Bulk I/O Dispatch" in the Linux block layer specifically to suit multitenant, multi-tasking shared Big Data environments. Hard disk drives (HDDs) form the backbone of data center storage. The data access time in HDDs is majorly governed by disk arm movements, which usually occurs when data is not accessed sequentially. Big Data applications exhibit evident sequentiality but due to the contentions amongst other I/O submitting applications, the I/O accesses get multiplexed which leads to higher disk arm movements. BID schemes aim to exploit the inherent I/O sequentiality of Big Data applications to improve the overall I/O completion time by reducing the avoidable disk arm movements. In the first part, we propose a dynamically adaptable block I/O scheduling scheme BID-HDD for disk based storage. BID-HDD tries to recreate the sequentiality in I/O access in order to provide performance isolation to each I/O submitting process. Through trace driven simulation based experiments with cloud emulating MapReduce benchmarks, we show the effectiveness of BID-HDD which results in 28-52% lesser time for all I/O requests than the best performing Linux disk schedulers. In the second part, we propose a hybrid scheme BID-Hybrid to exploit SCM's (SSDs) superior random performance to further avoid contentions at disk based storage. BID-Hybrid is able to efficiently offload non-bulky interruptions from HDD request queue to SSD queue using BID-HDD for disk request processing and multi-q FIFO architecture for SSD. This results in performance gain of 6-23% for MapReduce workloads when compared to BID-HDD and 33-54% over best performing Linux scheduling scheme. BID schemes as a whole is aimed to avoid contentions for disk based storage I/Os following system constraints without compromising SLAs.

show abstract

Section: Block Layer Developments Mostly I/o Schedulingmentioning

confidence: 99%

Host managed contention avoidance storage solutions for Big Data

Mishra

Somani

2017

J Big Data

View full text Add to dashboard Cite

show abstract

“…The ultimate criterion for being responsive is often whether the response delay is short enough to satisfy the user's needs. Most prior studies in enhancing responsiveness of mobile apps [11,12,18,21,24] have taken as their motivation that responsiveness critically a↵ects users' experience. It is therefore natural to expect that these studies have used some metrics to measure how much their proposed techniques enhance users' experience.…”

Section: Problem Definition and Motivationmentioning

confidence: 99%

“…Another direction to improve the responsiveness is through disk optimizations [11,12,21]. They have used launch delay reduction as the responsiveness metric.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

SatScore

Zhao

Zhou

Shen

2014

Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing

View full text Add to dashboard Cite

Important for user experience on mobile devices, app launch responsiveness has received many recent attentions. This paper reveals a principled pitfall in previous studies. Most of these studies have used average reduction of response delays as the metric for responsiveness. Through a systematic user study and statistical analysis, this paper shows that the metric fails to faithfully reflect user experienced responsiveness. To avoid the pitfall, a straight-forward solution is to employ users' direct feedback as the responsiveness metric, which is unfortunately hard to obtain. This paper presents the promise of solving the dilemma through a SatScore model. It further demonstrates some new opportunities for responsiveness enhancement enabled by the SatScore model.

show abstract

“…BFQ also allows the device to achieve a high aggregate throughput. BFQ-v1 is an enhanced version of BFQ [2], containing several improvements to better boost throughput and, above all, containing a few special heuristics to guarantee a high application and system responsiveness. The effectiveness of these heuristics is probably one of the reasons for the high popularity gained by BFQ.…”

Section: Introductionmentioning

confidence: 99%

Evolution of the BFQ Storage-I/O Scheduler

Valente

Avanzini

2015

2015 Mobile Systems Technologies Workshop (MST)

Self Cite

View full text Add to dashboard Cite

An accurate storage-I/O scheduler, named Budget Fair Queueing (BFQ), was integrated with a special set of heuristics a few years ago. The resulting, improved scheduler, codenamed BFQ-v1, was able to guarantee a number of desirable service properties, including a high responsiveness, to applications and system services. In the intervening years, BFQ-v1 has become relatively popular on desktop and handheld systems, and has further evolved. But no official, comprehensive and concentrated documentation has been provided about the improvements that have followed each other. In this paper we fill this documentation gap, by describing the current, last version of BFQ (v7r8). We also show the performance of BFQ-v7r8 through some experimental results, in terms of throughput and application responsiveness, and on both an HDD and an SSD.

show abstract

Improving application responsiveness with the BFQ disk I/O scheduler

Cited by 9 publications

References 14 publications

Host managed contention avoidance storage solutions for Big Data

Host managed contention avoidance storage solutions for Big Data

SatScore

Evolution of the BFQ Storage-I/O Scheduler

Contact Info

Product

Resources

About