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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230116130341.lci7hixndnxvjuhz@quack3>
Date:   Mon, 16 Jan 2023 14:03:41 +0100
From:   Jan Kara <jack@...e.cz>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, arie.vanderhoeven@...gate.com,
        rory.c.chen@...gate.com, glen.valante@...aro.org,
        damien.lemoal@...nsource.wdc.com
Subject: Re: [PATCH V13 REBASED 0/8] block, bfq: extend bfq to support
 multi-actuator drives

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 <jack@...e.com>
SUSE Labs, CR