On Wed, Sep 15, 2021 at 04:07:26PM +0200, Peter Zijlstra wrote:
> +SYSCALL_DEFINE4(futex_waitv, struct futex_waitv __user *, waiters,
> + unsigned int, nr_futexes, unsigned int, flags,
> + struct __kernel_timespec __user *, timo)
So I utterly detest timespec.. it makes no sense what so ever.
Can't we just, for new syscalls, simply use a s64 nsec argument and call
it a day?
Thomas, Arnd ?
On 9/15/21 8:37 AM, Peter Zijlstra wrote:
> I utterly detest timespec.. it makes no sense what so ever.
>
> Can't we just, for new syscalls, simply use a s64 nsec argument and call
> it a day?
This would stop working in the year 2262. Not a good idea.
Any improvements on struct timespec should be a strict superset, not a
subset. For example, you could advocate a signed 128-bit argument
counting in units of attoseconds (10⁻¹⁸ s), the highest power-of-1000
resolution that does not lose info when converting from struct timespec.
This could use __int128 on platforms that have it, a two-integer struct
otherwise.
I'm not sure this is a hill I'd want to die on. That being said, it
would be cool to keep up with the people in the building near mine who
are researching attosecond imaging (tricky because the uncertainty
principle means attosecond laser pulses must have very broad spectra).
And extending struct timespec on the low end is clearly the way to go,
since its high end already goes back well before the Big Bang.
I hope you don't mind my going off the deep end a bit here. Still, the
point is that if we're going to improve on struct timespec then it
really should be an improvement.
On Wed, Sep 15, 2021 at 5:39 PM Peter Zijlstra <[email protected]> wrote:
>
> On Wed, Sep 15, 2021 at 04:07:26PM +0200, Peter Zijlstra wrote:
> > +SYSCALL_DEFINE4(futex_waitv, struct futex_waitv __user *, waiters,
> > + unsigned int, nr_futexes, unsigned int, flags,
> > + struct __kernel_timespec __user *, timo)
>
> So I utterly detest timespec.. it makes no sense what so ever.
>
> Can't we just, for new syscalls, simply use a s64 nsec argument and call
> it a day?
>
> Thomas, Arnd ?
Do you mean passing the nanoseconds by value instead of a pointer?
I think that would be worse, since that means having incompatible calling
conventions between 32-bit and 64-bit architectures, and even
between 32-bit architectures that have different requirements for 64-bit
function arguments.
If we pass it by reference, there is much less to gain from changing the
timespec to plain nanoseconds. I wouldn't object to that, but I don't
see it helping much either. It would work for relative timeouts, but the
general trend seems to be to specify timeouts as absolute times,
and that would force each caller to read the time using clock_gettime()
and then convert it to nanoseconds before adding the timeout.
Specifying the timeout in terms of 32-bit relative milliseconds would the
way that epoll() does would be really simple, but that still feels odd.
Arnd
On Wed, Sep 15 2021 at 10:34, Paul Eggert wrote:
> On 9/15/21 8:37 AM, Peter Zijlstra wrote:
>> I utterly detest timespec.. it makes no sense what so ever.
>>
>> Can't we just, for new syscalls, simply use a s64 nsec argument and call
>> it a day?
>
> This would stop working in the year 2262. Not a good idea.
Make it u64 and it stops in 2552, i.e. 584 years from now which is
plenty. Lot's of the kernel internal timekeeping will stop working at
that point, so that interface is the least of my worries. And TBH, my
worries about the Y2552 problem are extremly close to zero.
> Any improvements on struct timespec should be a strict superset, not a
> subset. For example, you could advocate a signed 128-bit argument
> counting in units of attoseconds (10⁻¹⁸ s), the highest power-of-1000
> resolution that does not lose info when converting from struct
> timespec.
Which requires a 128bit division on every syscall for no value at all.
Thanks,
tglx
Às 11:49 de 16/09/21, Thomas Gleixner escreveu:
> On Wed, Sep 15 2021 at 10:34, Paul Eggert wrote:
>
>> On 9/15/21 8:37 AM, Peter Zijlstra wrote:
>>> I utterly detest timespec.. it makes no sense what so ever.
>>>
>>> Can't we just, for new syscalls, simply use a s64 nsec argument and call
>>> it a day?
>>
>> This would stop working in the year 2262. Not a good idea.
>
> Make it u64 and it stops in 2552, i.e. 584 years from now which is
> plenty. Lot's of the kernel internal timekeeping will stop working at
> that point, so that interface is the least of my worries. And TBH, my
> worries about the Y2552 problem are extremly close to zero.
>
What do we win by using u64 instead of timespec?
Or what's so bad about timespec?