From: Keith Busch <[email protected]>
To: lizetao <[email protected]>
Cc: Keith Busch <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [PATCHv2 0/6] ublk zero-copy support
Date: Thu, 13 Feb 2025 09:06:33 -0700 [thread overview]
Message-ID: <Z64YiTHfvA-_NCsl@kbusch-mbp> (raw)
In-Reply-To: <[email protected]>
On Thu, Feb 13, 2025 at 03:12:43PM +0000, lizetao wrote:
> I tested this patch set. When I use null as the device, the test results are like your v1.
> When the bs is 4k, there is a slight improvement; when the bs is 64k, there is a significant improvement.
> However, when I used loop as the device, I found that there was no improvement, whether using 4k or 64k. As follow:
>
> ublk add -t loop -f ./ublk-loop.img
> ublk add -t loop -f ./ublk-loop-zerocopy.img
>
> fio -filename=/dev/ublkb0 -direct=1 -rw=read -iodepth=1 -ioengine=io_uring -bs=128k -size=5G
> read: IOPS=2015, BW=126MiB/s (132MB/s)(1260MiB/10005msec)
>
> fio -filename=/dev/ublkb1 -direct=1 -rw=read -iodepth=1 -ioengine=io_uring -bs=128k -size=5G
> read: IOPS=1998, BW=125MiB/s (131MB/s)(1250MiB/10005msec)
>
>
> So, this patch set is optimized for null type devices? Or if I've missed any key information, please let me know.
What do you get if if you run your fio job directly on your
ublk-loop.img file?
Throughput should improve until you've saturated the backend device.
Once you hit that point, the primary benefit of zero-copy come from
decreased memory and CPU utilizations.
next prev parent reply other threads:[~2025-02-13 16:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 0:56 [PATCHv2 0/6] ublk zero-copy support Keith Busch
2025-02-11 0:56 ` [PATCHv2 1/6] io_uring: use node for import Keith Busch
2025-02-11 0:56 ` [PATCHv2 2/6] io_uring: create resource release callback Keith Busch
2025-02-13 1:31 ` Pavel Begunkov
2025-02-13 1:58 ` Keith Busch
2025-02-13 13:06 ` Pavel Begunkov
2025-02-11 0:56 ` [PATCHv2 3/6] io_uring: add support for kernel registered bvecs Keith Busch
2025-02-13 1:33 ` Pavel Begunkov
2025-02-14 3:30 ` Ming Lei
2025-02-14 15:26 ` Keith Busch
2025-02-15 1:34 ` Ming Lei
2025-02-18 20:34 ` Keith Busch
2025-02-11 0:56 ` [PATCHv2 4/6] ublk: zc register/unregister bvec Keith Busch
2025-02-12 2:49 ` Ming Lei
2025-02-12 4:11 ` Keith Busch
2025-02-12 9:24 ` Ming Lei
2025-02-12 14:59 ` Keith Busch
2025-02-13 2:12 ` Pavel Begunkov
2025-02-11 0:56 ` [PATCHv2 5/6] io_uring: add abstraction for buf_table rsrc data Keith Busch
2025-02-11 0:56 ` [PATCHv2 6/6] io_uring: cache nodes and mapped buffers Keith Busch
2025-02-11 16:47 ` Keith Busch
2025-02-12 2:29 ` [PATCHv2 0/6] ublk zero-copy support Ming Lei
2025-02-12 15:28 ` Keith Busch
2025-02-12 16:06 ` Pavel Begunkov
2025-02-13 1:52 ` Ming Lei
2025-02-13 15:12 ` lizetao
2025-02-13 16:06 ` Keith Busch [this message]
2025-02-14 3:39 ` lizetao
2025-02-14 2:41 ` Ming Lei
2025-02-14 4:21 ` lizetao
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=Z64YiTHfvA-_NCsl@kbusch-mbp \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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