From: Bart Van Assche <bvanassche@acm.org>
To: Yu Kuai <yukuai3@huawei.com>,
axboe@kernel.dk, andriy.shevchenko@linux.intel.com,
john.garry@huawei.com, ming.lei@redhat.com, qiulaibin@huawei.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
yi.zhang@huawei.com
Subject: Re: [PATCH -next RFC v3 0/8] improve tag allocation under heavy load
Date: Sun, 24 Apr 2022 20:09:01 -0700 [thread overview]
Message-ID: <450b5ab6-fb82-06dc-2a11-e0b464901c74@acm.org> (raw)
In-Reply-To: <20220415101053.554495-1-yukuai3@huawei.com>
On 4/15/22 03:10, Yu Kuai wrote:
> The single io performance(randwrite):
>
> | bs | 128k | 256k | 512k | 1m | 1280k | 2m | 4m |
> | -------- | ---- | ---- | ---- | ---- | ----- | ---- | ---- |
> | bw MiB/s | 20.1 | 33.4 | 51.8 | 67.1 | 74.7 | 82.9 | 82.9 |
Although the above data is interesting, it is not sufficient. The above
data comes from a setup with a single hard disk. There are many other
configurations that are relevant (hard disk array, high speed NVMe, QD=1
USB stick, ...) but for which no conclusions can be drawn from the above
data.
Another question is whether the approach of this patch series is the
right approach? I would expect that round-robin wakeup of waiters would
be ideal from a fairness point of view. However, there are patches in
this patch series that guarantee that wakeup of tag waiters won't happen
in a round robin fashion.
Thanks,
Bart.
next prev parent reply other threads:[~2022-04-25 3:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 10:10 [PATCH -next RFC v3 0/8] improve tag allocation under heavy load Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 1/8] sbitmap: record the number of waiters for each waitqueue Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 2/8] blk-mq: call 'bt_wait_ptr()' later in blk_mq_get_tag() Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 3/8] sbitmap: make sure waitqueues are balanced Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 4/8] blk-mq: don't preempt tag under heavy load Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 5/8] sbitmap: force tag preemption if free tags are sufficient Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 6/8] blk-mq: force tag preemption for split bios Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 7/8] blk-mq: record how many tags are needed for splited bio Yu Kuai
2022-04-15 10:10 ` [PATCH -next RFC v3 8/8] sbitmap: wake up the number of threads based on required tags Yu Kuai
2022-04-24 2:43 ` [PATCH -next RFC v3 0/8] improve tag allocation under heavy load yukuai (C)
2022-04-25 3:24 ` Damien Le Moal
2022-04-25 6:14 ` yukuai (C)
2022-04-25 6:23 ` Damien Le Moal
2022-04-25 6:47 ` yukuai (C)
2022-04-25 6:50 ` Damien Le Moal
2022-04-25 7:05 ` yukuai (C)
2022-04-25 7:06 ` Damien Le Moal
2022-04-25 7:28 ` yukuai (C)
2022-04-25 11:20 ` Damien Le Moal
2022-04-25 13:42 ` yukuai (C)
2022-04-25 3:09 ` Bart Van Assche [this message]
2022-04-25 3:27 ` yukuai (C)
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=450b5ab6-fb82-06dc-2a11-e0b464901c74@acm.org \
--to=bvanassche@acm.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=john.garry@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=qiulaibin@huawei.com \
--cc=yi.zhang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.