From: Pavel Begunkov <asml.silence@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, io-uring@vger.kernel.org
Subject: Re: [PATCH 2/3] io_uring/poll: flag request as having gone through poll wake machinery
Date: Mon, 14 Jul 2025 16:45:33 +0100 [thread overview]
Message-ID: <4abbf820-11c9-4e01-9f95-5ccc45f0f20c@gmail.com> (raw)
In-Reply-To: <e24aaa01-e703-4a6b-9d1c-bf5deacbda86@kernel.dk>
On 7/14/25 15:54, Jens Axboe wrote:
> On 7/14/25 3:26 AM, Pavel Begunkov wrote:
>> On 7/12/25 21:59, Jens Axboe wrote:
>>> On 7/12/25 5:39 AM, Pavel Begunkov wrote:
>>>> On 7/12/25 00:59, Jens Axboe wrote:
>>>>> No functional changes in this patch, just in preparation for being able
...>>>> Same, it's overhead for all polled requests for a not clear gain.
>>>> Just move it to the arming function. It's also not correct to
>>>> keep it here, if that's what you care about.
>>>
>>> Not too worried about overhead, for an unlocked or. The whole poll
>>
>> You know, I wrote this machinery and optimised it, I'm not saying it
>> to just piss you off, I still need it to work well for zcrx :)
>
> This was not a critique of the code, it's just a generic statement on
> the serialization around poll triggering is obviously a lot more
> expensive than basic flag checking or setting. Every comment is not a
> backhanded attack on someones code.
Not taken this way, it works well enough for such highly concurrent
synchronisation.
>> Not going into details, but it's not such a simple unlocked or. And
>> death by a thousand is never old either.
>
> That's obviously true, I was just trying to set expectations that a
> single flag mask is not really a big deal. If the idea and feature was
> fully solidified and useful, then arguing that adding a bit or is a
> problem is nonsense.
Quite the opppsite, it should be argued about, and not because "or"
is expensive, but because it's a write in a nuanced place.
By that standard, we could never add anything to
> the code, only remove. At the same time, adding frivolous code is of
> course always a bad idea.
--
Pavel Begunkov
next prev parent reply other threads:[~2025-07-14 15:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <[PATCHSET 0/3] Add support for IORING_CQE_F_POLLED>
2025-07-11 23:59 ` Jens Axboe
2025-07-11 23:59 ` [PATCH 1/3] io_uring/poll: cleanup apoll freeing Jens Axboe
2025-07-11 23:59 ` [PATCH 2/3] io_uring/poll: flag request as having gone through poll wake machinery Jens Axboe
2025-07-12 11:39 ` Pavel Begunkov
2025-07-12 20:59 ` Jens Axboe
2025-07-14 9:26 ` Pavel Begunkov
2025-07-14 14:54 ` Jens Axboe
2025-07-14 15:45 ` Pavel Begunkov [this message]
2025-07-14 17:51 ` Jens Axboe
2025-07-18 10:20 ` Pavel Begunkov
2025-07-11 23:59 ` [PATCH 3/3] io_uring: add IORING_CQE_F_POLLED flag Jens Axboe
2025-07-12 11:34 ` Pavel Begunkov
2025-07-12 14:49 ` Pavel Begunkov
2025-07-12 21:02 ` Jens Axboe
2025-07-12 23:05 ` 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 \
--in-reply-to=4abbf820-11c9-4e01-9f95-5ccc45f0f20c@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@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.