All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chenliang Li <cliang01.li@samsung.com>
To: anuj1072538@gmail.com
Cc: asml.silence@gmail.com, axboe@kernel.dk, cliang01.li@samsung.com,
	gost.dev@samsung.com, io-uring@vger.kernel.org,
	joshi.k@samsung.com, kundan.kumar@samsung.com,
	peiwei.li@samsung.com
Subject: Re: [PATCH v3 0/5] io_uring/rsrc: coalescing multi-hugepage registered buffers
Date: Tue, 14 May 2024 08:16:14 +0800	[thread overview]
Message-ID: <20240514001614.566276-1-cliang01.li@samsung.com> (raw)
In-Reply-To: <CACzX3At7k+kspDrzz-=HhFGHpcgi+O8S6D+fPND7imfiodHTOg@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="y", Size: 1260 bytes --]

On Mon, 13 May 2024 17:39:37 +0530, Anuj Gupta wrote:
> On Mon, May 13, 2024 at 1:59 PM Chenliang Li <cliang01.li@samsung.com> wrote:
>>
>> Registered buffers are stored and processed in the form of bvec array,
>> each bvec element typically points to a PAGE_SIZE page but can also work
>> with hugepages. Specifically, a buffer consisting of a hugepage is
>> coalesced to use only one hugepage bvec entry during registration.
>> This coalescing feature helps to save both the space and DMA-mapping time.
>>
>> However, currently the coalescing feature doesn't work for multi-hugepage
>> buffers. For a buffer with several 2M hugepages, we still split it into
>> thousands of 4K page bvec entries while in fact, we can just use a
>> handful of hugepage bvecs.
>>
>> This patch series enables coalescing registered buffers with more than
>> one hugepages. It optimizes the DMA-mapping time and saves memory for
>> these kind of buffers.
>>
>> Perf diff of 8M(4*2M) hugepage fixed buffer fio test:
>>
>> fio/t/io_uring -d64 -s32 -c32 -b8388608 -p0 -B1 -F0 -n1 -O1 -r10 \
>> -R1 /dev/nvme0n1
> 
> It seems you modified t/io_uring to allocate from hugepages. It would be nice
> to mention that part here.

Yeah I forgot to mention that. Thanks for pointing out.

      parent reply	other threads:[~2024-05-14  0:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240513082306epcas5p2fd8ea6fd88b2c4ab1d17b1508fe2af97@epcas5p2.samsung.com>
2024-05-13  8:22 ` [PATCH v3 0/5] io_uring/rsrc: coalescing multi-hugepage registered buffers Chenliang Li
     [not found]   ` <CGME20240513082308epcas5p3c38ce4d44fa1613988bbae84eaec41b9@epcas5p3.samsung.com>
2024-05-13  8:22     ` [PATCH v3 1/5] io_uring/rsrc: add hugepage buffer coalesce helpers Chenliang Li
     [not found]   ` <CGME20240513082310epcas5p27576a80eae3ee09e40102b179ce46fa9@epcas5p2.samsung.com>
2024-05-13  8:22     ` [PATCH v3 2/5] io_uring/rsrc: store folio shift and mask into imu Chenliang Li
     [not found]   ` <CGME20240513082311epcas5p3556d301a1f1faca0c6b613555324861e@epcas5p3.samsung.com>
2024-05-13  8:22     ` [PATCH v3 3/5] io_uring/rsrc: add init and account functions for coalesced imus Chenliang Li
     [not found]   ` <CGME20240513082313epcas5p2a781d3393e4bf92d13d04ac62bb28fb7@epcas5p2.samsung.com>
2024-05-13  8:22     ` [PATCH v3 4/5] io_uring/rsrc: enable multi-hugepage buffer coalescing Chenliang Li
2024-05-13 12:11       ` Anuj gupta
     [not found]   ` <CGME20240513082314epcas5p309fa70575596792b5c9923ce76a3778f@epcas5p3.samsung.com>
2024-05-13  8:23     ` [PATCH v3 5/5] liburing: add test cases for hugepage registered buffers Chenliang Li
2024-05-13 12:09   ` [PATCH v3 0/5] io_uring/rsrc: coalescing multi-hugepage " Anuj gupta
2024-05-13 13:40     ` Jens Axboe
     [not found]       ` <CGME20240514001813epcas5p455c8a3dd6f2164626a526c05f7fd92c4@epcas5p4.samsung.com>
2024-05-14  0:18         ` Chenliang Li
     [not found]     ` <CGME20240514001443epcas5p362c60c233ed2aecdb5e144099b44d9be@epcas5p3.samsung.com>
2024-05-14  0:14       ` [PATCH v3 4/5] io_uring/rsrc: enable multi-hugepage buffer coalescing Chenliang Li
     [not found]     ` <CGME20240514001620epcas5p10d8c08ffc3dbd746213df21e47df19f7@epcas5p1.samsung.com>
2024-05-14  0:16       ` Chenliang Li [this message]

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=20240514001614.566276-1-cliang01.li@samsung.com \
    --to=cliang01.li@samsung.com \
    --cc=anuj1072538@gmail.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=gost.dev@samsung.com \
    --cc=io-uring@vger.kernel.org \
    --cc=joshi.k@samsung.com \
    --cc=kundan.kumar@samsung.com \
    --cc=peiwei.li@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 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.