On 5/30/24 16:38, Jens Axboe wrote:
On 5/30/24 3:17 PM, Keith Busch wrote:
On Thu, May 30, 2024 at 02:02:20PM -0700, Bart Van Assche wrote:
Thank you for having run this test. I propose that users who want better
fairness than what my patch supports use an appropriate mechanism for
improving fairness (e.g. blk-iocost or blk-iolat). This leaves the choice
between maximum performance and maximum fairness to the user. Does this
sound good to you?
I really don't know, I generally test with low latency devices and
disable those blk services because their overhead is too high. I'm
probably not the target demographic for those mechanisms. :)
Yeah same. But outside of that, needing to configure something else is
also a bit of a cop out. From the initial posting, it's quoting 2.9%
gain. For lots of cases, adding blk-iocost or blk-iolat would be MORE
than a 2.9% hit.
That said, I'd love to kill the code, but I still don't think we have
good numbers on it. Are yours fully stable? What does the qd=1 test do
_without_ having anyone compete with it? Is the bandwidth nicely
balanced if each does qd=32? I'm again kindly asking for some testing
:-)
I just wanted to push the edge cases to see where things diverge.
Perhaps Jens can weigh in on the impact and suggested remedies?
Don't think we have enough data yet to make the call...
Hi Jens,
I'm interested in this patch because it solves a UFS performance issue. Because
this patch significantly improves performance for UFS devices, we are carrying
some form of this patch since more than two years in the Android kernel tree.
Thanks,
Bart.
