All of lore.kernel.org
 help / color / mirror / Atom feed
From: lizetao <lizetao1@huawei.com>
To: Keith Busch <kbusch@meta.com>
Cc: "io-uring@vger.kernel.org" <io-uring@vger.kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: RE: [PATCHv2 0/6] ublk zero-copy support
Date: Thu, 13 Feb 2025 15:12:43 +0000	[thread overview]
Message-ID: <83fd69a8aa77450093acb1ada05c188f@huawei.com> (raw)
In-Reply-To: <20250211005646.222452-1-kbusch@meta.com>

Hi,

> -----Original Message-----
> From: Keith Busch <kbusch@meta.com>
> Sent: Tuesday, February 11, 2025 8:57 AM
> To: ming.lei@redhat.com; asml.silence@gmail.com; axboe@kernel.dk; linux-
> block@vger.kernel.org; io-uring@vger.kernel.org
> Cc: bernd@bsbernd.com; Keith Busch <kbusch@kernel.org>
> Subject: [PATCHv2 0/6] ublk zero-copy support
> 
> From: Keith Busch <kbusch@kernel.org>
> 
> Previous version was discussed here:
> 
>   https://lore.kernel.org/linux-block/20250203154517.937623-1-
> kbusch@meta.com/
> 
> The same ublksrv reference code in that link was used to test the kernel side
> changes.
> 
> Before listing what has changed, I want to mention what is the same: the
> reliance on the ring ctx lock to serialize the register ahead of any use. I'm not
> ignoring the feedback; I just don't have a solid answer right now, and want to
> progress on the other fronts in the meantime.
> 
> Here's what's different from the previous:
> 
>  - Introduced an optional 'release' callback when the resource node is
>    no longer referenced. The callback addresses any buggy applications
>    that may complete their request and unregister their index while IO
>    is in flight. This obviates any need to take extra page references
>    since it prevents the request from completing.
> 
>  - Removed peeking into the io_cache element size and instead use a
>    more intuitive bvec segment count limit to decide if we're caching
>    the imu (suggested by Pavel).
> 
>  - Dropped the const request changes; it's not needed.

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.


---
Li Zetao


  parent reply	other threads:[~2025-02-13 15:12 UTC|newest]

Thread overview: 32+ 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 15:17   ` kernel test robot
2025-02-11 16:47   ` Keith Busch
2025-02-12  1:42   ` kernel test robot
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 [this message]
2025-02-13 16:06   ` Keith Busch
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=83fd69a8aa77450093acb1ada05c188f@huawei.com \
    --to=lizetao1@huawei.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=kbusch@meta.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.