LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: "yukuai (C)" <yukuai3@huawei.com>, axboe@kernel.dk, ming.lei@redhat.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
yi.zhang@huawei.com
Subject: Re: [PATCH] blk-mq: allow hardware queue to get more tag while sharing a tag set
Date: Thu, 5 Aug 2021 19:43:11 -0700 [thread overview]
Message-ID: <b4603b71-4306-4542-e4fb-bf30133f89a8@acm.org> (raw)
In-Reply-To: <a63fbd36-5a43-e412-c0a2-a06730945a13@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
On 8/5/21 6:50 PM, yukuai (C) wrote:
> After applying this configuration, the number of null_blk in my
> machine is about 650k(330k before). Is this still too low?
That seems low to me. If I run the attached script on a six year old
desktop with an eight core i7-4790 CPU it reports a little more than 5
million IOPS. Has kernel debugging perhaps been enabled in the kernel on
the test setup? Or is the system perhaps slowed down by security
mitigations?
> By the way, there are no performance degradation.
Please wait with drawing a conclusion until you can run a workload on
your setup of several million IOPS.
Thanks,
Bart.
[-- Attachment #2: nullb-iops --]
[-- Type: text/plain, Size: 1188 bytes --]
#!/bin/bash
if [ -e /sys/kernel/config/nullb ]; then
for d in /sys/kernel/config/nullb/*; do
[ -d "$d" ] && rmdir "$d"
done
fi
numcpus=$(grep -c ^processor /proc/cpuinfo)
modprobe -r null_blk
[ -e /sys/module/null_blk ] && exit $?
modprobe null_blk nr_devices=0 &&
udevadm settle &&
cd /sys/kernel/config/nullb &&
mkdir nullb0 &&
cd nullb0 &&
echo 0 > completion_nsec &&
echo 512 > blocksize &&
echo 0 > home_node &&
echo 0 > irqmode &&
echo 1024 > size &&
echo 0 > memory_backed &&
echo 2 > queue_mode &&
echo 1 > power ||
exit $?
(
cd /sys/block/nullb0/queue &&
echo 2 > rq_affinity
) || exit $?
iodepth=${1:-1}
runtime=30
args=()
if [ "$iodepth" = 1 ]; then
args+=(--ioengine=psync)
else
args+=(--ioengine=io_uring --iodepth_batch=$((iodepth/2)))
fi
args+=(--iodepth=$iodepth --name=nullb0 --filename=/dev/nullb0\
--rw=read --bs=4096 --loops=$((1<<20)) --direct=1 --numjobs=$numcpus \
--thread --runtime=$runtime --invalidate=1 --gtod_reduce=1 \
--group_reporting=1 --ioscheduler=none)
if numactl -m 0 -N 0 echo >&/dev/null; then
numactl -m 0 -N 0 -- fio "${args[@]}"
else
fio "${args[@]}"
fi
next prev parent reply other threads:[~2021-08-06 2:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 3:18 Yu Kuai
2021-07-12 3:19 ` yukuai (C)
2021-07-20 12:33 ` yukuai (C)
2021-07-31 7:13 ` yukuai (C)
2021-07-31 17:15 ` Bart Van Assche
2021-08-02 13:34 ` yukuai (C)
2021-08-02 16:17 ` Bart Van Assche
2021-08-03 2:57 ` yukuai (C)
2021-08-03 18:38 ` Bart Van Assche
2021-08-06 1:50 ` yukuai (C)
2021-08-06 2:43 ` Bart Van Assche [this message]
2021-08-14 9:43 ` yukuai (C)
2021-08-16 4:16 ` 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=b4603b71-4306-4542-e4fb-bf30133f89a8@acm.org \
--to=bvanassche@acm.org \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
--subject='Re: [PATCH] blk-mq: allow hardware queue to get more tag while sharing a tag set' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).