Re: [PATCH V13 REBASED 0/8] block, bfq: extend bfq to support multi-actuator drives

[Paolo Valente]

> Il giorno 16 gen 2023, alle ore 14:03, Jan Kara <jack@xxxxxxx> 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 <jack@xxxxxxxx>
> SUSE Labs, CR