hrtimer_forward() semantics when using non-high-res timers

hrtimer_forward() semantics when using non-high-res timers

[Eduardo Habkost]

Hi, Thomas,

I've been looking at a timer problem on KVM recently[1] and I've got a
question about the expected semantics of hrtimer_forward().

The problem I am looking at is related to having proper accouting of
missed ticks on the KVM timer code when it the host has lost timer
ticks because of high CPU load, or because it doesn't have hrtimers
enabled. hrtimer_forward_now() overrun accounting looked perfect for
the task of checking how many ticks we have lost.

However hrtimer_forward() limits the interval parameter to the timer
resolution, making it useless for calculating how many timer periods we've
lost because of too-low timer resolution. I am even a bit surprised no
other code needs a hrtimer_forward-like function for that, yet.

For example: if we want to account for a tick every 1 ms and the host
has HZ=250 and no high-resolution timers, calling hrtimer_forward_now()
on every timer tick will normally return 1 because it will count how
many 4 ms periods were added to the timer expiration time. However,
I would like to calculate how many 1 ms periods I've lost, no matter
what the real timer resolution is.

I could do my own missed-ticks calculation, but the hrtimer_forward()
logic would be perfect for my needs if it didn't have the resolution check
code, and I don't feel like duplicating part of hrtimer_forward(). Do you
think it would make sense to have on the timers API a hrtimer_forward-like
function that doesn't have the interval lower-limit?


[1] http://marc.info/?l=kvm&m=122728725028262&w=2

-- 
Eduardo