Re: mstohz and hztoms

[Christos Zoulas <christos%zoulas.com@localhost>]

> On Sep 28, 2019, at 6:53 PM, matthew green <mrg%eterna.com.au@localhost> 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