On 4 July 2014 21:44, Frederic Weisbecker fweisbec@gmail.com wrote:
While we are debating on changelogs, here are a few more structural concerns:
So above we have all the required informations. They are just a bit disorganized. Maybe try to synthesize things a bit. I tend to use the following changelog architecture, lets hope I'm not proposing something even more confusing...
Initial situation
When we reach the end of the tick handler, we unconditionally reschedule the next tick to the next jiffy. Then on irq exit, the nohz code overrides that setting if needed and defers the next tick as far away in the future as possible.
Now when we actually don't need any tick in the future (ie: expires == KTIME_MAX), low-res and high-res behave differently. In high-res mode we cancel the next tick that was previously scheduled from the tick handler. That's what we want. OTOH in low-res mode we don't do anything and the next tick is still scheduled to jiffies + 1.
Resulting issue
As a result when no tick is needed in low-res dynticks mode, we can recursively get a spurious tick every jiffy because then the next tick is always reprogrammed from the tick handler and is never cancelled. And this can happen indefinetly until some subsystem actually needs a precise tick in the future and only then we eventually overwrite the tick handler setting and defer the next one.
Solution:
+1.
Thanks.