> On Sep 28, 2019, at 6:53 PM, matthew green wrote:
>
>> Comments?
>
> i like the clean up. it's clearly a step forward.
>
> i only don't understand why 32 bit platforms can't handle
> large values here but 64 bit ones can. is it only so that the
> 32 bit platforms don't use 64 bit maths when it's not needed?
There was a comment about not using 64 bit math on 32
bit platforms, but I don't understand why. It is not like those
are being called too frequently. Of course I might be missing
something...
> it just seems wrong to me to limit 32 bit artificially here,
> and it's not like it's _that_ difficult to overflow 32 bit hz.
> i run with HZ=1000 on some systems, like alpha does by
> default. that gives you 49 days. even with standard HZ=100
> it's only 16 months or so. (hmm, i wonder if these macros
> compile nothing with HZ=1000 kernels. be nice to confirm or
> add a hack :-)
>
> can we make the 32 bit version smarter about accepting small
> values with 32 bit maths, but large or non-constant values
> with 64 bit maths?
>
Yes, now that they are inline functions (we can safely do more
complex things.
> perhaps an explicit mstohz64() could handle the cases if we
> know they will exist, since most probably _know_ they are
> dealing with short intervals.
>
> there's just something about the artificial limit here that
> is bugging me...
I will take a look at all the uses and come back with a proposal.
christos
