Re: [PATCH v2 2/2] io_uring/timeout: immediate timeout arg

[Jens Axboe <axboe@kernel.dk>]

On 2/27/26 2:09 PM, Pavel Begunkov wrote:
> On 2/27/26 20:19, Jens Axboe wrote:
>> On 2/27/26 1:03 PM, Pavel Begunkov wrote:
>>> On 2/27/26 19:39, Jens Axboe wrote:
> ...
>>>> I don't think it's about length of it - if you can avoid the div by
>>>> doing ns_to_timespec64(), that might be very useful? Would make
>>>
>>> hrtimer_start(&data->timer, timespec64_to_ktime(data->ts), mode);
>>>                                     ^^^
>>>
>>> io_uring just needs to flip it and use ktime, but I left it for later.
>>
>> I think we should go all the way with this if we're doing the immediate
>> mode. And I do think that is a good idea. Doing a half-way thing doesn't
>> make much sense to me.
> 
> One time people will tell you don't do premature optimisations,
> merge the main thing first, another time it's the other way around,
> you can never guess.

IMHO this isn't premature optimization, it's more about just doing it
right in the first place.

> In either case, it's useful by itself. Div is not that expensive
> to be a break dealer, and div by constant will usually get
> replaced with a mul by modern compilers.

Agree, and that's likely what it does here. It's just why not avoid it
in the first place if possible. That's not premature optimization.

>>>> userspace simpler too potentially, and basically make the immediate mode
>>>> _exactly_ the same as the non-immediate mode, it just delivers the
>>>> __kernel_timespec in a different way.
>>>
>>> I very much want to believe that everything about kernel_timespec has
>>> some deep meaning, but I fail to see why they split it as sec/ns and
>>> left invalid ranges for ns, why ns is signed, and why even after a
>>> large revamp one of the fields doesn't use a fixed width type.
>>> I'm not sure exactly like it is actually a good idea.
>>
>> But that's the API for anything timing related, whether it be timeval,
>> timespec, or __kernel_timespec the latter obviously only existing
>> because everybody else could not be bothered to do a proper 32 vs 64-bit
>> agnostic type before. Hence that's the API that people know and use,
>> there's no deeper meaning other than that. And I agree, it's kind of
>> crap in how you can have an invalid range and it gets masked.
>>
>> It's like like I'm a huge __kernel_timespec fan, but for consistency's
>> sake, I do like it. With a clock source, then it does start to make
>> sense. 
> 
> What's about clock source? I'm curious

Just that timespec/timeval/whatever usually go with a clocksource, vs
some isolated nsec value.

>> Not that I think there's a lot of ABS use cases, I'd expect
>> relative to be what people generally use here. But at least then the
> 
> It's probably common enough. Not the "wake me on Monday at 5am" kind,
> but rather get the current time and then recalculating intervals
> from it. Would be nice to return the wake up time as well in a CQE,
> if only it was free.

Yeah could be, it's always hard to know. Which is why it's nice to error
on the side of "let's just support both upfront" if it's feasible.

>> IMMED API addition will just work regardless of what you do in the app.
>> That's better than someone a few revisions later than saying "hey that's
>> cool, can we do ABS too which I use because of X and Y" and then having
>> to hack that on top.
> 
> Hack it up in the user program? I didn't get it.

No, I mean needing to retrofit ABS support on the kernel side for IMMED
up front.

-- 
Jens Axboe