Gleb Natapov <g...@redhat.com> writes: >> That's a bug. >> >> The next period calculation should not be based on the last period + >> length of period but rather on the current time + delta to next period >> boundary. >> > I disagree that this is a bug. This is by design to account for timer > signals that was delivered to late.
It's immediate reinjection of ticks missed due to timer delay such that even if you select tdf=slew, you're still doing reinject. Maybe it's just semantics of whether it's a bug or feature, but hopefully you agree that making tdf=slew gradually deliver those missed ticks would be a good thing. > > >> IOW, if we shouldn't arm timers to expire backwards in time from when >> the event occurred. That should be accounted as a missed tick. >> > Not all users of qemu_timer have their own missed tick accounting so > qemu_timer provides general one. We can create another time source > for qemu_timer without this behaviour and use it in RTC. I think we probably should start by getting one device to have good catchup behavior and then we can look at generalizing. There are other things we've never done that would help too (like allowing for non-base 10 timer frequencies) that would make some of the time calculations easier. But I think at this point, I need to send some patches which requires some hacking first.. Regards, Anthony Liguori > > > -- > Gleb.
