From: Bart Van Assche <bvanassche@acm.org>
To: Yu Kuai <yukuai1@huaweicloud.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Ming Lei <ming.lei@redhat.com>, Keith Busch <kbusch@kernel.org>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Ed Tsai <ed.tsai@mediatek.com>, "yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] block: Improve shared tag set performance
Date: Sat, 21 Oct 2023 09:21:01 -0700 [thread overview]
Message-ID: <b3325fe5-4208-432b-97a9-d40f5cdda4b0@acm.org> (raw)
In-Reply-To: <31ca731b-7ffb-185a-fdbc-9e4821e2b46f@huaweicloud.com>
On 10/21/23 00:32, Yu Kuai wrote:
> Sorry for such huge delay, I was struggled on implementing a smoothly
> algorithm to borrow tags and return borrowed tags, and later I put this
> on ice and focus on other stuff.
>
> I had an idea to implement a state machine, however, the amount of code
> was aggressive and I gave up. And later, I implemented a simple version,
> and I tested it in your case, 32 tags and 2 shared node, result looks
> good(see below), however, I'm not confident this can work well general.
>
> Anyway, I'll send a new RFC verion for this, and please let me know if
> you still think this approch is unacceptable.
>
> Thanks,
> Kuai
>
> Test script:
>
> [global]
> ioengine=libaio
> iodepth=2
> bs=4k
> direct=1
> rw=randrw
> group_reporting
>
> [sda]
> numjobs=32
> filename=/dev/sda
>
> [sdb]
> numjobs=1
> filename=/dev/sdb
>
> Test result, by monitor new debugfs entry shared_tag_info:
> time active available
> sda sdb sda sdb
> 0 0 0 32 32
> 1 16 2 16 16 -> start fair sharing
> 2 19 2 20 16
> 3 24 2 24 16
> 4 26 2 28 16 -> borrow 32/8=4 tags each round
> 5 28 2 28 16 -> save at lease 4 tags for sdb
Hi Yu,
Thank you for having shared these results. What is the unit of the
numbers in the time column?
In the above I see that more tags are assigned to sda than to sdb
although I/O is being submitted to both LUNs. I think the current
algoritm defines fairness as dividing tags in a fair way across active
LUNs. Do the above results show that tags are divided per active job
instead of per active LUN? If so, I'm not sure that everyone will agree
that this is a fair way to distribute tags ...
Thanks,
Bart.
next prev parent reply other threads:[~2023-10-21 16:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 18:00 [PATCH] block: Improve shared tag set performance Bart Van Assche
2023-10-20 4:41 ` Christoph Hellwig
2023-10-20 16:17 ` Bart Van Assche
2023-10-20 16:25 ` Keith Busch
2023-10-20 16:45 ` Bart Van Assche
2023-10-20 17:09 ` Keith Busch
2023-10-20 17:54 ` Bart Van Assche
2023-10-21 1:31 ` Ming Lei
2023-10-21 16:13 ` Bart Van Assche
2023-10-23 3:44 ` Ming Lei
2023-10-20 19:11 ` Bart Van Assche
2023-10-21 7:32 ` Yu Kuai
2023-10-21 16:21 ` Bart Van Assche [this message]
2023-10-23 1:11 ` Yu Kuai
-- strict thread matches above, loose matches on Subject: below --
2023-01-02 17:39 Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3325fe5-4208-432b-97a9-d40f5cdda4b0@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@opensource.wdc.com \
--cc=ed.tsai@mediatek.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox