public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Subject: Re: [RFC 0/9] scrap 24 bytes from io_kiocb
Date: Sun, 12 Jul 2020 14:32:41 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 7/12/20 11:34 AM, Pavel Begunkov wrote:
> On 12/07/2020 18:59, Jens Axboe wrote:
>> On 7/12/20 3:41 AM, Pavel Begunkov wrote:
>>> Make io_kiocb slimmer by 24 bytes mainly by revising lists usage. The
>>> drawback is adding extra kmalloc in draining path, but that's a slow
>>> path, so meh. It also frees some space for the deferred completion path
>>> if would be needed in the future, but the main idea here is to shrink it
>>> to 3 cachelines in the end.
>>>
>>> I'm not happy yet with a few details, so that's not final, but it would
>>> be lovely to hear some feedback.
>>
>> I think it looks pretty good, most of the changes are straight forward.
>> Adding a completion entry that shares the submit space is a good idea,
>> and really helps bring it together.
>>
>> From a quick look, the only part I'm not super crazy about is patch #3.
> 
> Thanks!
> 
>> I'd probably rather use a generic list name and not unionize the tw
>> lists.
> 
> I don't care much, but without compiler's help always have troubles
> finding and distinguishing something as generic as "list".

To me, it's easier to verify that we're doing the right thing when they
use the same list member. Otherwise you have to cross reference two
different names, easier to shoot yourself in the foot that way. So I'd
prefer just retaining it as 'list' or something generic.

> BTW, I thought out how to bring it down to 3 cache lines, but that would
> require taking io_wq_work out of io_kiocb and kmalloc'ing it on demand.
> And there should also be a bunch of nice side effects like improving apoll.

How would this work with the current use of io_wq_work as storage for
whatever bits we're hanging on to? I guess it could work with a prep
series first more cleanly separating it, though I do feel like we've
been getting closer to that already.

Definitely always interested in shrinking io_kiocb, just need to keep
an eye out for the fast(er) paths not needing two allocations (and
frees) for a single request.

-- 
Jens Axboe


  reply	other threads:[~2020-07-12 20:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-12  9:41 [RFC 0/9] scrap 24 bytes from io_kiocb Pavel Begunkov
2020-07-12  9:41 ` [PATCH 1/9] io_uring: share completion list w/ per-op space Pavel Begunkov
2020-07-12  9:41 ` [PATCH 2/9] io_uring: rename ctx->poll into ctx->iopoll Pavel Begunkov
2020-07-12  9:41 ` [PATCH 3/9] io_uring: use inflight_entry list for iopolling Pavel Begunkov
2020-07-12  9:41 ` [PATCH 4/9] io_uring: use competion list for CQ overflow Pavel Begunkov
2020-07-12  9:41 ` [PATCH 5/9] io_uring: add req->timeout.list Pavel Begunkov
2020-07-12  9:41 ` [PATCH 6/9] io_uring: remove init for unused list Pavel Begunkov
2020-07-12  9:41 ` [PATCH 7/9] io_uring: kill rq->list and allocate it on demand Pavel Begunkov
2020-07-12  9:41 ` [PATCH 8/9] io_uring: remove sequence from io_kiocb Pavel Begunkov
2020-07-12  9:41 ` [PATCH 9/9] io_uring: place cflags into completion data Pavel Begunkov
2020-07-12 15:59 ` [RFC 0/9] scrap 24 bytes from io_kiocb Jens Axboe
2020-07-12 17:34   ` Pavel Begunkov
2020-07-12 20:32     ` Jens Axboe [this message]
2020-07-13  8:17       ` Pavel Begunkov
2020-07-13  8:17       ` Pavel Begunkov
2020-07-13 14:12         ` Jens Axboe
2020-07-13 20:45           ` Pavel Begunkov
2020-07-13 21:00             ` Jens Axboe

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 \
    [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