On 13 Feb 2014, at 16:20, Peter Maydell wrote: > On 13 February 2014 16:09, Alex Bligh <a...@alex.org.uk> 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
