On 1/17/24 23:31, Christoph Hellwig wrote:
On Tue, Jan 16, 2024 at 09:36:27AM -0800, Bart Van Assche wrote:
My concern is that the complexity of the algorithm introduced by that patch
series is significant. I prefer code that is easy to understand. This is why
I haven't started yet with a detailed review. If anyone else wants to review
that patch series that's fine with me.
Given that simply disabling fair sharing isn't going to fly we'll need
something more complex than that.
The question is how much complexity do we need, and for that it would
be good to collect the use cases first.
Hi Christoph,
Patch "[PATCH v6 2/4] scsi: core: Make fair tag sharing configurable in
the host template" of this series can be dropped by making the UFS
driver call blk_mq_update_fair_sharing() directly.
So far two use cases have been identified: setups with an UFSHCI 3.0
host controller and ATA controllers for which all storage devices have
similar latency characteristics. Both storage controllers have a queue
depth limit of 32 commands.
It seems to me that disabling fair sharing will always result in better
performance than any algorithm that realizes fair sharing (including the
current algorithm). Only a single boolean needs to be tested to
determine whether or not fair sharing should be disabled. Any fair
sharing algorithm that we can come up with will be significantly more
complex than testing a single boolean. I think this is a strong argument
for adding support for disabling fair sharing.
If anyone wants to improve the fair sharing algorithm that's fine with
me. However, I do not plan to work on this myself.
Thanks,
Bart.
