From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>, 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 11:51:01 -0600 [thread overview]
Message-ID: <9b874b96-f79e-4a1e-a971-9504f3f209ca@kernel.dk> (raw)
In-Reply-To: <4abbf820-11c9-4e01-9f95-5ccc45f0f20c@gmail.com>
On 7/14/25 9:45 AM, Pavel Begunkov wrote:
> 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.
Certainly, no complaints!
>>> 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.
I think that's orthogonal - should it be commented? Definitely yes. This
is sadly true for a lot of the code in there, but doesn't mean we should
add more.
But all moot so far, at least until it can move forward, if at all.
--
Jens Axboe
next prev parent reply other threads:[~2025-07-14 17:51 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
2025-07-14 17:51 ` Jens Axboe [this message]
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=9b874b96-f79e-4a1e-a971-9504f3f209ca@kernel.dk \
--to=axboe@kernel.dk \
--cc=asml.silence@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox