Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [PATCH V13 REBASED 0/8] block, bfq: extend bfq to support
 multi-actuator drives
From:   Paolo Valente <paolo.valente@linaro.org>
In-Reply-To: <20230116130341.lci7hixndnxvjuhz@quack3>
Date:   Mon, 16 Jan 2023 19:09:23 +0100
Cc:     Jens Axboe <axboe@kernel.dk>,
        linux-block <linux-block@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Arie van der Hoeven <arie.vanderhoeven@seagate.com>,
        Rory Chen <rory.c.chen@seagate.com>, glen.valante@linaro.org,
        damien.lemoal@opensource.wdc.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D3BE66C-8E36-4D32-BEF3-B500133CA66B@linaro.org>
References: <20230103145503.71712-1-paolo.valente@linaro.org>
 <20230116130341.lci7hixndnxvjuhz@quack3>
To:     Jan Kara <jack@suse.cz>
Precedence: bulk


> Il giorno 16 gen 2023, alle ore 14:03, Jan Kara <jack@suse.cz> ha =
scritto:
>=20
> Hi Paolo!
>=20
> 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=E2=80=99s 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.

> =46rom 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 :)
>=20
> 								Honza
>=20
> --=20
> Jan Kara <jack@suse.com>
> SUSE Labs, CR