Alternatively instead of NSEC_PER_SEC/HZ, we could always drop theYes, may be this would be a safer option. Thinking about this I was wondering if we should always use max_deferement/10, because I did not think that there would ever be a case where NSEC_PER_SEC/HZ would be greater. If NSEC_PER_SEC/HZ was greater than max_deferement/10 this would imply that the clocksource would wrap after only 10 jiffies, if I have the math right...
larger of NSEC_PER_SEC/HZ or max_deferment/10? That way we should scale
up without a problem.
Right, but even with such limitiations, if an arch can skip every 5
ticks, they probably will try, right? :)
That sounds reasonable to me.
One final question, I noticed in clocksource.h that the definition of function cyc2ns returns a type of s64, however, in the function itself a variable of type u64 is used and returned. Should this function be modified as follows?
static inline s64 cyc2ns(struct clocksource *cs, cycle_t cycles)
{
- u64 ret = (u64)cycles;
+ s64 ret = (s64)cycles;
ret = (ret * cs->mult) >> cs->shift;
return ret;
}
Damn. So this brings up an issue I had missed prior.
I'll have to think about how that would change
timekeeping_max_deferment() and how we'd have to calculate a reasonable
max efficiently.
Other then this issue (which is my fault for not noticing it earlier),
you're patch looks great. I just feel badly for making you rev this
thing over and over.
One option if you're itching to push it in and be done with it: Make
timekeeping_max_deferment() return just 1 second for now. Your patch
provides the right infrastructure for the timekeeping code to provide
its limits to the clockevents code. So you can use a safe short constant
value for now, and we can extend that out correctly in a future patch.
Sorry again for not catching this until now. :(