Re: [Qemu-devel] timer issue on 1.7.0 and later

[Alex Bligh]

On 13 Feb 2014, at 16:20, Peter Maydell wrote:

> On 13 February 2014 16:09, Alex Bligh <address@hidden> wrote:
>> I suspect the issue is not walking the lists, but calling
>> qemu_notify, breaking out of mainloop select etc. etc.; that
>> happens on a timer_modify but not on a timer_del. We could
>> fix this so that it only happened if the timer's expiry
>> time was reduced in timer_mod (I think).
> 
> Surely you only want to do all that work if the fiddling
> with the timer means the next most immediate deadline
> has changed? If you have two timers, and A is going to
> expire before B, then even reducing B's expiry time shouldn't
> trigger renotifying unless it's reduced so much it will
> expire before A.

Correct.

The current code (timer_mod_ns_locked) runs the rearm code
if the modified timer is at the front of the timer queue
(only). So if you modify B (in your example above) whether
you extend or reduce the time, it will only 'rearm' if
B now occurs before A. However, if you modify A, it will
currently rearm whether you reduce the expiry time of
A (correct) or whether you extend it so long as it doesn't
now expire after B (this could perhaps be optimised).

So it's not quite as bad as you think.

-- 
Alex Bligh