public inbox for [email protected]
 help / color / mirror / Atom feed
* [PATCHSET RFC 0/4] Support for mapping SQ/CQ rings into huge page
@ 2023-04-19 22:48 Jens Axboe
  2023-04-19 22:48 ` [PATCH 1/4] io_uring: remove sq/cq_off memset Jens Axboe
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Jens Axboe @ 2023-04-19 22:48 UTC (permalink / raw)
  To: io-uring

Hi,

io_uring SQ/CQ rings are allocated by the kernel from contigious, normal
pages, and then the application mmap()'s the rings into userspace. This
works fine, but does require contigious pages to be available for the
given SQ and CQ ring sizes. As uptime increases on a given system, so
does memory fragmentation. Entropy is invevitable.

This patchset adds support for the application passing in a pre-allocated
huge page, and then placing the rings in that. This reduces the need for
contigious pages, and also reduces the TLB pressure for larger rings.

The liburing huge.2 branch has support for using this trivially.
Applications may use the normal ring init helpers and set
IORING_SETUP_NO_MMAP, in which case a huge page will get allocated for
them and used. Or they may use io_uring_queue_init_mem() and pass in
a pre-allocated huge page, getting the amount of it used returned. This
allows placing multiple rings into a single huge page.

-- 
Jens Axboe



^ permalink raw reply	[flat|nested] 6+ messages in thread
* [PATCHSET 0/4 v2] Support for mapping SQ/CQ rings into huge page
@ 2023-05-13 14:16 Jens Axboe
  2023-05-13 14:16 ` [PATCH 1/4] io_uring: remove sq/cq_off memset Jens Axboe
  0 siblings, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2023-05-13 14:16 UTC (permalink / raw)
  To: io-uring

Hi,

io_uring SQ/CQ rings are allocated by the kernel from contigious, normal
pages, and then the application mmap()'s the rings into userspace. This
works fine, but does require contigious pages to be available for the
given SQ and CQ ring sizes. As uptime increases on a given system, so
does memory fragmentation. Entropy is invevitable.

This patchset adds support for the application passing in a pre-allocated
huge page, and then placing the rings in that. This reduces the need for
contigious pages, and also reduces the TLB pressure for larger rings.

The liburing huge.2 branch has support for using this trivially.
Applications may use the normal ring init helpers and set
IORING_SETUP_NO_MMAP, in which case a huge page will get allocated for
them and used. Or they may use io_uring_queue_init_mem() and pass in
a pre-allocated huge page, getting the amount of it used returned. This
allows placing multiple rings into a single huge page.

Changes since v1:
- Mandate that we're using a single page. May be a normal page if we
  don't need a lot of memory, or a huge page if the ring itself takes
  up more space than a single normal page.

-- 
Jens Axboe



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-05-13 14:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-19 22:48 [PATCHSET RFC 0/4] Support for mapping SQ/CQ rings into huge page Jens Axboe
2023-04-19 22:48 ` [PATCH 1/4] io_uring: remove sq/cq_off memset Jens Axboe
2023-04-19 22:48 ` [PATCH 2/4] io_uring: return error pointer from io_mem_alloc() Jens Axboe
2023-04-19 22:48 ` [PATCH 3/4] io_uring: add ring freeing helper Jens Axboe
2023-04-19 22:48 ` [PATCH 4/4] io_uring: support for user allocated memory for rings/sqes Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2023-05-13 14:16 [PATCHSET 0/4 v2] Support for mapping SQ/CQ rings into huge page Jens Axboe
2023-05-13 14:16 ` [PATCH 1/4] io_uring: remove sq/cq_off memset Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox