From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: "yukuai (C)" <yukuai3@huawei.com>,
axboe@kernel.dk, bvanassche@acm.org,
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: Mon, 25 Apr 2022 20:20:15 +0900 [thread overview]
Message-ID: <88d9e8f4-cc5a-4897-f511-8f5b7d9a0acd@opensource.wdc.com> (raw)
In-Reply-To: <35f18afa-0db1-b423-5824-4d5631b0422f@huawei.com>
On 4/25/22 16:28, yukuai (C) wrote:
> 在 2022/04/25 15:06, Damien Le Moal 写道:
>
>>>> By the way, did you check that doing something like:
>>>>
>>>> echo 2048 > /sys/block/sdX/queue/nr_requests
>>>>
>>>> improves performance for your high number of jobs test case ?
>>>
>>> Yes, performance will not degrade when numjobs is not greater than 256
>>> in this case.
>>
>> That is my thinking as well. I am asking if did check that (did you run it ?).
>
> Hi,
>
> I'm sure I ran it with 256 jobs before.
>
> However, I didn't run it with 512 jobs. And following is the result I
> just tested:
What was nr_requests ? The default 64 ?
If you increase that number, do you see better throughput/more requests
being sequential ?
>
> ratio of sequential io: 49.1%
>
> Read|Write seek
>
> cnt 99338, zero cnt 48753
>
> >=(KB) .. <(KB) : count ratio |distribution
> |
> 0 .. 1 : 48753 49.1%
> |########################################|
> 1 .. 2 : 0 0.0% |
> |
> 2 .. 4 : 0 0.0% |
> |
> 4 .. 8 : 0 0.0% |
> |
> 8 .. 16 : 0 0.0% |
> |
> 16 .. 32 : 0 0.0% |
> |
> 32 .. 64 : 0 0.0% |
> |
> 64 .. 128 : 4975 5.0% |#####
> |
> 128 .. 256 : 4439 4.5% |####
> |
> 256 .. 512 : 2615 2.6% |###
> |
> 512 .. 1024 : 967 1.0% |#
> |
> 1024 .. 2048 : 213 0.2% |#
> |
> 2048 .. 4096 : 375 0.4% |#
> |
> 4096 .. 8192 : 723 0.7% |#
> |
> 8192 .. 16384 : 1436 1.4% |##
> |
> 16384 .. 32768 : 2626 2.6% |###
> |
> 32768 .. 65536 : 4197 4.2% |####
> |
> 65536 .. 131072 : 6431 6.5% |######
> |
> 131072 .. 262144 : 7590 7.6% |#######
> |
> 262144 .. 524288 : 6433 6.5% |######
> |
> 524288 .. 1048576 : 4583 4.6% |####
> |
> 1048576 .. 2097152 : 2237 2.3% |##
> |
> 2097152 .. 4194304 : 489 0.5% |#
> |
> 4194304 .. 8388608 : 83 0.1% |#
> |
> 8388608 .. 16777216 : 36 0.0% |#
> |
> 16777216 .. 33554432 : 0 0.0% |
> |
> 33554432 .. 67108864 : 0 0.0% |
> |
> 67108864 .. 134217728 : 137 0.1% |#
> |
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-04-25 11:20 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 [this message]
2022-04-25 13:42 ` yukuai (C)
2022-04-25 3:09 ` Bart Van Assche
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=88d9e8f4-cc5a-4897-f511-8f5b7d9a0acd@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--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.