All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Hengyu Liang <hengyul@cs.unc.edu>
Cc: Pavel Begunkov <asml.silence@gmail.com>,
	David Wei <dw@davidwei.uk>,
	io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] io_uring: do not charge user provided SQ/CQ rings to RLIMIT_MEMLOCK
Date: Thu, 8 Oct 2026 13:11:11 -0600	[thread overview]
Message-ID: <3b9d9c06-c6e8-4166-87d9-c7c220ad0b58@kernel.dk> (raw)
In-Reply-To: <20261008170611.1285778-1-hengyul@cs.unc.edu>

On 10/8/26 11:06 AM, Hengyu Liang wrote:
> This goes on top of io_uring-7.3 (c746673517c6), as discussed in [2].
> 
> Tested on that branch as a user without CAP_IPC_LOCK and the default
> 8 MiB limit:
> 
>                                                   before  after
>   program above                                       21     64
>   the same with io_uring_queue_init()                 64     64
>   30 processes x 142 NO_MMAP rings of 64 entries       7     30
> 
> The last row is what 30 PostgreSQL 18 clusters with default settings
> create. The number is how many of them got all their rings.
> 
> The per-user locked_vm count stays balanced over ring create, close and
> resize. Provided buffer rings and IORING_REGISTER_MEM_REGION regions on
> user memory are charged as before. Every liburing test gives the same
> result with and without the patch.
> 
> Not changed here: provided buffer rings on user memory, which is what
> io_uring_setup_buf_ring() registers, were not charged in v6.13 either
> (64 of 64 rings of 32768 entries then, 16 now). I can send a patch for
> those as well if you want them handled the same way.

Honestly, after taking a closer look at this, I think we're better off
with your original patch and one on top for pbuf rings. Please check:

https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=io_uring-7.3

for the top 2 commits. If you can re-test one more time, that'd be
great...

-- 
Jens Axboe

      reply	other threads:[~2026-10-08 19:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 21:38 [PATCHSET 0/2] Fix memlock account for kernel backed memory Jens Axboe
2026-10-07 21:38 ` [PATCH 1/2] Revert "io_uring/memmap: account the pages a compound region really uses" Jens Axboe
2026-10-07 21:38 ` [PATCH 2/2] io_uring/memmap: only charge pinned user memory to RLIMIT_MEMLOCK Jens Axboe
2026-10-08  4:57   ` Hengyu Liang
2026-10-08 14:54     ` Jens Axboe
2026-10-08 17:06       ` [PATCH] io_uring: do not charge user provided SQ/CQ rings " Hengyu Liang
2026-10-08 19:11         ` Jens Axboe [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=3b9d9c06-c6e8-4166-87d9-c7c220ad0b58@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=dw@davidwei.uk \
    --cc=hengyul@cs.unc.edu \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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.