public inbox for [email protected]
 help / color / mirror / Atom feed
From: Keith Busch <[email protected]>
To: Caleb Sander Mateos <[email protected]>
Cc: Keith Busch <[email protected]>,
	[email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected]
Subject: Re: [PATCHv3 5/5] io_uring: cache nodes and mapped buffers
Date: Tue, 18 Feb 2025 14:12:07 -0700	[thread overview]
Message-ID: <Z7T3p_sdl0IrWRj8@kbusch-mbp> (raw)
In-Reply-To: <CADUfDZqb-55yAJU1GbDF3tqW=6DhNP+SV3Msx+Sv5GPRHt+s0w@mail.gmail.com>

On Tue, Feb 18, 2025 at 12:42:19PM -0800, Caleb Sander Mateos wrote:
> Right, that's a good point that there's a tradeoff. I think always
> allocating space for IO_CACHED_BVECS_SEGS bvecs is reasonable. Maybe
> IO_CACHED_BVECS_SEGS should be slightly smaller so the allocation fits
> nicely in a power of 2? Currently it looks to take up 560 bytes:
> >>> 48 + 16 * 32
> 560
> 
> Using IO_CACHED_BVECS_SEGS = 29 instead would make it 512 bytes:
> >>> 48 + 16 * 29
> 512

Right, and it's even smaller on 32-bit architectures.

I don't think it's worth optimizing the cached object size like this.
It's probably better we optimize for a particular transfer size. If your
bvec is physically discontiguous, 32 bvecs gets you to 128k transfers on
a 4k page platform. That seems like a common transfer size for
benchmarking throughput. It is arbitrary at the end of the day, so I'm
not set on that if there's an argument for something different.

      reply	other threads:[~2025-02-18 21:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14 15:43 [PATCHv3 0/5] ublk zero-copy support Keith Busch
2025-02-14 15:43 ` [PATCHv3 1/5] io_uring: move fixed buffer import to issue path Keith Busch
2025-02-18 20:32   ` Caleb Sander Mateos
2025-02-14 15:43 ` [PATCHv3 2/5] io_uring: add support for kernel registered bvecs Keith Busch
2025-02-14 20:38   ` Caleb Sander Mateos
2025-02-18 19:59     ` Keith Busch
2025-02-18 20:20       ` Caleb Sander Mateos
2025-02-14 15:43 ` [PATCHv3 3/5] ublk: zc register/unregister bvec Keith Busch
2025-02-14 15:43 ` [PATCHv3 4/5] io_uring: add abstraction for buf_table rsrc data Keith Busch
2025-02-14 15:43 ` [PATCHv3 5/5] io_uring: cache nodes and mapped buffers Keith Busch
2025-02-15  2:22   ` Caleb Sander Mateos
2025-02-16 22:43     ` Caleb Sander Mateos
2025-02-18 20:12       ` Keith Busch
2025-02-18 20:45         ` Caleb Sander Mateos
2025-02-18 20:09     ` Keith Busch
2025-02-18 20:42       ` Caleb Sander Mateos
2025-02-18 21:12         ` Keith Busch [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=Z7T3p_sdl0IrWRj8@kbusch-mbp \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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