Message ID | 20240513082300.515905-1-cliang01.li@samsung.com (mailing list archive) |
---|---|
Headers | show |
Series | io_uring/rsrc: coalescing multi-hugepage registered buffers | expand |
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. -- Anuj Gupta
On 5/13/24 6:09 AM, 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. Yes, please just send a separate series/patch for both liburing and fio. This series should be strictly the kernel side changes required, then reference/link the postings for the t/io_uring and liburing test case(s) in the cover letter.
On Mon, 13 May 2024 17:41:14 +0530, Anuj Gupta wrote: > On Mon, May 13, 2024 at 2:04 PM Chenliang Li <cliang01.li@samsung.com> wrote: >> >> Modify the original buffer registration path to expand the >> one-hugepage coalescing feature to work with multi-hugepage >> buffers. Separated from previous patches to make it more >> easily reviewed. > The last line should not be a part of the commit description IMO. Will delete that. Thanks.
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.
On Mon, 13 May 2024 07:40:13 -0600, Jens Axboe wrote: > Yes, please just send a separate series/patch for both liburing and fio. > This series should be strictly the kernel side changes required, then > reference/link the postings for the t/io_uring and liburing test case(s) > in the cover letter. Sure, will send them separately.