Hi,
rebased V13 [2].
Here is the whole description of this patch series again. This
extension addresses the following issue. Single-LUN multi-actuator
SCSI drives, as well as all multi-actuator SATA drives appear as a
single device to the I/O subsystem [1]. Yet they address commands to
different actuators internally, as a function of Logical Block
Addressing (LBAs). A given sector is reachable by only one of the
actuators. For example, Seagate’s Serial Advanced Technology
Attachment (SATA) version contains two actuators and maps the lower
half of the SATA LBA space to the lower actuator and the upper half to
the upper actuator.
Evidently, to fully utilize actuators, no actuator must be left idle
or underutilized while there is pending I/O for it. To reach this
goal, the block layer must somehow control the load of each actuator
individually. This series enriches BFQ with such a per-actuator
control, as a first step. Then it also adds a simple mechanism for
guaranteeing that actuators with pending I/O are never left idle.
See [1] for a more detailed overview of the problem and of the
solutions implemented in this patch series. There you will also find
some preliminary performance results.
Thanks,
Paolo
[1] https://www.linaro.org/blog/budget-fair-queueing-bfq-linux-io-scheduler-optimizations-for-multi-actuator-sata-hard-drives/
[2] https://lore.kernel.org/lkml/[email protected]/t/
Davide Zini (3):
block, bfq: split also async bfq_queues on a per-actuator basis
block, bfq: inject I/O to underutilized actuators
block, bfq: balance I/O injection among underutilized actuators
Federico Gavioli (1):
block, bfq: retrieve independent access ranges from request queue
Paolo Valente (4):
block, bfq: split sync bfq_queues on a per-actuator basis
block, bfq: forbid stable merging of queues associated with different
actuators
block, bfq: move io_cq-persistent bfqq data into a dedicated struct
block, bfq: turn bfqq_data into an array in bfq_io_cq
block/bfq-cgroup.c | 93 +++----
block/bfq-iosched.c | 587 ++++++++++++++++++++++++++++++--------------
block/bfq-iosched.h | 142 ++++++++---
block/bfq-wf2q.c | 2 +-
4 files changed, 565 insertions(+), 259 deletions(-)
--
2.20.1
On Tue, 03 Jan 2023 15:54:55 +0100, Paolo Valente wrote:
> rebased V13 [2].
>
> Here is the whole description of this patch series again. This
> extension addresses the following issue. Single-LUN multi-actuator
> SCSI drives, as well as all multi-actuator SATA drives appear as a
> single device to the I/O subsystem [1]. Yet they address commands to
> different actuators internally, as a function of Logical Block
> Addressing (LBAs). A given sector is reachable by only one of the
> actuators. For example, Seagate’s Serial Advanced Technology
> Attachment (SATA) version contains two actuators and maps the lower
> half of the SATA LBA space to the lower actuator and the upper half to
> the upper actuator.
>
> [...]
Applied, thanks!
[1/8] block, bfq: split sync bfq_queues on a per-actuator basis
commit: abc653033297fb39c097f9e18cc4ab42a5c00a23
[2/8] block, bfq: forbid stable merging of queues associated with different actuators
commit: d591f14a59ed700caff6db734ecf558387d38f35
[3/8] block, bfq: move io_cq-persistent bfqq data into a dedicated struct
commit: d85fed150b4efadf01ea3d12ba78285f6720f583
[4/8] block, bfq: turn bfqq_data into an array in bfq_io_cq
commit: 7cf744815a3cd94591b0227f3c63f533f3402a47
[5/8] block, bfq: split also async bfq_queues on a per-actuator basis
commit: 8249909fe789d7dc50f6749bbdf440d69ac46ac1
[6/8] block, bfq: retrieve independent access ranges from request queue
commit: b3d9aece342834ef3840b55a99a11dc82b1f96cc
[7/8] block, bfq: inject I/O to underutilized actuators
commit: 3f40467eb5ec1e4f383daff7f93c7494e7881fee
[8/8] block, bfq: balance I/O injection among underutilized actuators
commit: dd9b66eb9ed5c0e58098c336cb8e6329590564be
Best regards,
--
Jens Axboe
Hi Paolo!
On Tue 03-01-23 15:54:55, Paolo Valente wrote:
> Here is the whole description of this patch series again. This
> extension addresses the following issue. Single-LUN multi-actuator
> SCSI drives, as well as all multi-actuator SATA drives appear as a
> single device to the I/O subsystem [1]. Yet they address commands to
> different actuators internally, as a function of Logical Block
> Addressing (LBAs). A given sector is reachable by only one of the
> actuators. For example, Seagate’s Serial Advanced Technology
> Attachment (SATA) version contains two actuators and maps the lower
> half of the SATA LBA space to the lower actuator and the upper half to
> the upper actuator.
>
> Evidently, to fully utilize actuators, no actuator must be left idle
> or underutilized while there is pending I/O for it. To reach this
> goal, the block layer must somehow control the load of each actuator
> individually. This series enriches BFQ with such a per-actuator
> control, as a first step. Then it also adds a simple mechanism for
> guaranteeing that actuators with pending I/O are never left idle.
>
> See [1] for a more detailed overview of the problem and of the
> solutions implemented in this patch series. There you will also find
> some preliminary performance results.
Sorry, I didn't find time to look into this earlier. I've just had a
high-level look into the patches and I have one question: Did you consider
a solution where you'd basically duplicate all of the scheduling for each
actuator (thus making them effectively independent devices from the point
of view of BFQ)? From the first look it would look like somewhat simpler
solution than splitting all the BFQ queues and implementing special
injection mechanism for other actuators and perhaps lead to better
utilization of the actuators. OTOH the latecy and QoS for tasks using
multiple actuators would be probably worse because it would be basically
determined by the busiest of the actuators. So I'm asking mostly out of
curiosity :)
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
> Il giorno 16 gen 2023, alle ore 14:03, Jan Kara <[email protected]> ha scritto:
>
> Hi Paolo!
>
> On Tue 03-01-23 15:54:55, Paolo Valente wrote:
>> Here is the whole description of this patch series again. This
>> extension addresses the following issue. Single-LUN multi-actuator
>> SCSI drives, as well as all multi-actuator SATA drives appear as a
>> single device to the I/O subsystem [1]. Yet they address commands to
>> different actuators internally, as a function of Logical Block
>> Addressing (LBAs). A given sector is reachable by only one of the
>> actuators. For example, Seagate’s Serial Advanced Technology
>> Attachment (SATA) version contains two actuators and maps the lower
>> half of the SATA LBA space to the lower actuator and the upper half to
>> the upper actuator.
>>
>> Evidently, to fully utilize actuators, no actuator must be left idle
>> or underutilized while there is pending I/O for it. To reach this
>> goal, the block layer must somehow control the load of each actuator
>> individually. This series enriches BFQ with such a per-actuator
>> control, as a first step. Then it also adds a simple mechanism for
>> guaranteeing that actuators with pending I/O are never left idle.
>>
>> See [1] for a more detailed overview of the problem and of the
>> solutions implemented in this patch series. There you will also find
>> some preliminary performance results.
>
> Sorry, I didn't find time to look into this earlier. I've just had a
> high-level look into the patches and I have one question: Did you consider
> a solution where you'd basically duplicate all of the scheduling for each
> actuator (thus making them effectively independent devices from the point
> of view of BFQ)?
Yep, I did.
> From the first look it would look like somewhat simpler
> solution than splitting all the BFQ queues and implementing special
> injection mechanism for other actuators and perhaps lead to better
> utilization of the actuators. OTOH the latecy and QoS for tasks using
> multiple actuators would be probably worse because it would be basically
> determined by the busiest of the actuators.
Exactly, that's why I had to keep all queues in the same bucket.
Thanks for both asking and answering! :)
Jokes apart, thank you a lot for having a look at this contribution,
Paolo
> So I'm asking mostly out of
> curiosity :)
>
> Honza
>
> --
> Jan Kara <[email protected]>
> SUSE Labs, CR