On 13 February 2014 16:31, Alex Bligh <a...@alex.org.uk> wrote: > 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.
A little experimentation with the debugger for an SMP A9 guest suggests this may be a red herring anyway. Once it's got started, the only thing that was causing calls to timerlist_notify was the GUI, and if you run with -display none we don't call timerlist_notify at all at the point where we seem to be stalling. thanks -- PMM
