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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html