Re: [PATCH v3] blkcg: allocate struct blkcg_gq outside request queue spinlock

Hello, Tahsin. Generally looks good. Please see below. > @@ -184,24 +185,48 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, > + if (unlikely(!wb_congested)) { > ret = -ENOMEM; > goto err_put_css; > + } else if (unlikely(!blkg)) { > +

[PATCH RFC 05/14] block, bfq: add more fairness with writes and slow processes

This patch deals with two sources of unfairness, which can also cause high latencies and throughput loss. The first source is related to write requests. Write requests tend to starve read requests, basically because, on one side, writes are slower than reads, whereas, on the other side, storage

[PATCH RFC 07/14] block, bfq: reduce I/O latency for soft real-time applications

To guarantee a low latency also to the I/O requests issued by soft real-time applications, this patch introduces a further heuristic, which weight-raises (in the sense explained in the previous patch) also the queues associated to applications deemed as soft real-time. To be deemed as soft

[PATCH RFC 09/14] block, bfq: reduce latency during request-pool saturation

This patch introduces an heuristic that reduces latency when the I/O-request pool is saturated. This goal is achieved by disabling device idling, for non-weight-raised queues, when there are weight- raised queues with pending or in-flight requests. In fact, as explained in more detail in the

[PATCH RFC 03/14] block, bfq: improve throughput boosting

The feedback-loop algorithm used by BFQ to compute queue (process) budgets is basically a set of three update rules, one for each of the main reasons why a queue may be expired. If many processes suddenly switch from sporadic I/O to greedy and sequential I/O, then these rules are quite slow to

[PATCH RFC 13/14] block, bfq: boost the throughput with random I/O on NCQ-capable HDDs

This patch is basically the counterpart, for NCQ-capable rotational devices, of the previous patch. Exactly as the previous patch does on flash-based devices and for any workload, this patch disables device idling on rotational devices, but only for random I/O. In fact, only with these queues

[PATCH RFC 14/14] block, bfq: handle bursts of queue activations

From: Arianna Avanzini Many popular I/O-intensive services or applications spawn or reactivate many parallel threads/processes during short time intervals. Examples are systemd during boot or git grep. These services or applications benefit mostly from a high

[PATCH RFC 11/14] block, bfq: reduce idling only in symmetric scenarios

From: Arianna Avanzini A seeky queue (i..e, a queue containing random requests) is assigned a very small device-idling slice, for throughput issues. Unfortunately, given the process associated with a seeky queue, this behavior causes the following problem: if the

[PATCH RFC 10/14] block, bfq: add Early Queue Merge (EQM)

From: Arianna Avanzini A set of processes may happen to perform interleaved reads, i.e., read requests whose union would give rise to a sequential read pattern. There are two typical cases: first, processes reading fixed-size chunks of data at a fixed distance from

[PATCH RFC 08/14] block, bfq: preserve a low latency also with NCQ-capable drives

I/O schedulers typically allow NCQ-capable drives to prefetch I/O requests, as NCQ boosts the throughput exactly by prefetching and internally reordering requests. Unfortunately, as discussed in detail and shown experimentally in [1], this may cause fairness and latency guarantees to be violated.

[PATCH RFC 04/14] block, bfq: modify the peak-rate estimator

Unless the maximum budget B_max that BFQ can assign to a queue is set explicitly by the user, BFQ automatically updates B_max. In particular, BFQ dynamically sets B_max to the number of sectors that can be read, at the current estimated peak rate, during the maximum time, T_max, allowed before a

[PATCH RFC 12/14] block, bfq: boost the throughput on NCQ-capable flash-based devices

This patch boosts the throughput on NCQ-capable flash-based devices, while still preserving latency guarantees for interactive and soft real-time applications. The throughput is boosted by just not idling the device when the in-service queue remains empty, even if the queue is sync and has a

[PATCH RFC 06/14] block, bfq: improve responsiveness

This patch introduces a simple heuristic to load applications quickly, and to perform the I/O requested by interactive applications just as quickly. To this purpose, both a newly-created queue and a queue associated with an interactive application (we explain in a moment how BFQ decides whether

[PATCH RFC 00/14] Add the BFQ I/O Scheduler to blk-mq

Hi, at last, here is my first patch series meant for merging. It adds BFQ to blk-mq. Don't worry, in this message I won't bore you again with the wonderful properties of BFQ :) A quick update on the status of the code: thanks to Murphy's laws, in the last handful of days, 1) A kind of rare