linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Xiaobing Li <xiaobing.li@samsung.com>, miklos@szeredi.hu
Cc: linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org,
	bschubert@ddn.com, kbusch@kernel.org, amir73il@gmail.com,
	asml.silence@gmail.com, dw@davidwei.uk, josef@toxicpanda.com,
	joannelkoong@gmail.com, tom.leiming@gmail.com,
	joshi.k@samsung.com, kun.dou@samsung.com, peiwei.li@samsung.com,
	xue01.he@samsung.com
Subject: Re: [RFC] fuse: fuse support zero copy.
Date: Mon, 20 Oct 2025 10:15:00 -0600	[thread overview]
Message-ID: <1207928c-ad37-4ba0-b473-d38b9b2ce13c@kernel.dk> (raw)
In-Reply-To: <20251020080043.6638-1-xiaobing.li@samsung.com>

On 10/20/25 2:00 AM, Xiaobing Li wrote:
> DDN has enabled Fuse to support the io-uring solution, allowing us 
> to implement zero copy on this basis to further improve performance.
> 
> We have currently implemented zero copy using io-uring's fixed-buf 
> feature, further improving Fuse read performance. The general idea is 
> to first register a shared memory space through io_uring. 
> Then, libfuse in user space directly stores the read data into 
> the registered memory. The kernel then uses the io_uring_cmd_import_fixed 
> interface to directly retrieve the read results from the 
> shared memory, eliminating the need to copy data from user space to 
> kernel space.
> 
> The test data is as follows:
> 
> 4K IO size                                                           gain
> -------------------------------------------------------------------------
>                                |   no zero copy   |    zero copy  |  
> rw         iodepth     numjobs |      IOPS        |      IOPS     |    
> read          1           1    |      93K         |      97K      |  1.04
> read          16          16   |      169K        |      172K     |  1.02
> read          16          32   |      172K        |      173K     |  1.01
> read          32          16   |      169K        |      171K     |  1.01
> read          32          32   |      172K        |      173K     |  1.01
> randread      1           1    |      116K        |      136K     |  1.17
> randread      1           32   |      985K        |      994K     |  1.01
> randread      64          1    |      234K        |      261K     |  1.12
> randread      64          16   |      166K        |      168K     |  1.01
> randread      64          32   |      168K        |      170K     |  1.01
> 
> 128K IO size                                                         gain
> -------------------------------------------------------------------------
>                                |   no zero copy   |    zero copy  |
> rw         iodepth     numjobs |      IOPS        |      IOPS     |  
> read           1          1    |      24K         |      28K      |  1.17
> read           16         1    |      17K         |      19K      |  1.12
> read           64         1    |      17K         |      19K      |  1.12
> read           64         16   |      51K         |      55K      |  1.08
> read           64         32   |      54K         |      56K      |  1.04
> randread       1          1    |      24K         |      25K      |  1.04
> randread       16         1    |      17K         |      19K      |  1.12
> randread       64         1    |      16K         |      19K      |  1.19
> randread       64         16   |      50K         |      54K      |  1.08
> randread       64         32   |      49K         |      55K      |  1.12
> -------------------------------------------------------------------------
> 
> I will list the code after this solution is confirmed to be feasible.

Can you post the patches? A bit hard to tell if something is feasible or
the right direction without them :-)

-- 
Jens Axboe

  reply	other threads:[~2025-10-20 16:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20251020080512epcas5p4d3abbe6719fcb78fd65aea0524d85165@epcas5p4.samsung.com>
2025-10-20  8:00 ` [RFC] fuse: fuse support zero copy Xiaobing Li
2025-10-20 16:15   ` Jens Axboe [this message]
     [not found]     ` <CGME20251021052840epcas5p36d502a54805a8ba37c2929bb314088d4@epcas5p3.samsung.com>
2025-10-21  5:24       ` Xiaobing Li

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=1207928c-ad37-4ba0-b473-d38b9b2ce13c@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=amir73il@gmail.com \
    --cc=asml.silence@gmail.com \
    --cc=bschubert@ddn.com \
    --cc=dw@davidwei.uk \
    --cc=io-uring@vger.kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=josef@toxicpanda.com \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=kun.dou@samsung.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=peiwei.li@samsung.com \
    --cc=tom.leiming@gmail.com \
    --cc=xiaobing.li@samsung.com \
    --cc=xue01.he@samsung.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 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).