{"push_id":1363746057,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"89f1df984ec1962334954cb484e33fae2f91e345","before":"3cfa7c8e05c0120ea88a26e3a4b9841010f15cc3","commits":[{"sha":"9a0d466251e28da788244f3de3de5006c335250e","author":{"name":"Viresh Kumar","email":"4ca49bc1dcfdfc376d29da1eb07a3e0b3cd46daa@linaro.org"},"message":"nohz: Fix spurious periodic tick behaviour in low-res dynticks mode\n\nWhen we reach the end of the tick handler, we unconditionally reschedule\nthe next tick to the next jiffy. Then on irq exit, the nohz code\noverrides that setting if needed and defers the next tick as far away in\nthe future as possible.\n\nNow in the best dynticks case, when we actually don't need any tick in\nthe future (ie: expires == KTIME_MAX), low-res and high-res behave\ndifferently. What we want in this case is to cancel the next tick\nprogrammed by the previous one. That's what we do in high-res mode. OTOH\nwe lack a low-res mode equivalent of hrtimer_cancel() so we simply don't\ndo anything in this case and the next tick remains scheduled to jiffies + 1.\n\nAs a result, in low-res mode, when the dynticks code determines that no\ntick is needed in the future, we can recursively get a spurious tick\nevery jiffy because then the next tick is always reprogrammed from the\ntick handler and is never cancelled. And this can happen indefinetly\nuntil some subsystem actually needs a precise tick in the future and only\nthen we eventually overwrite the previous tick handler setting to defer\nthe next tick.\n\nWe are fixing this by introducing the ONESHOT_STOPPED mode which will\nlet us pause a clockevent when no further interrupt is needed. Meanwhile\nwe can't expect all drivers to support this new mode.\n\nSo lets reduce much of the symptoms by skipping the nohz-blind tick\nrescheduling from the tick-handler when the CPU is in dynticks mode.\nThat tick rescheduling wrongly assumed periodicity and the low-res\ndynticks code can't cancel such decision. This breaks the recursive (and\nthus the worst) part of the problem. In the worst case now, we'll get\nonly one extra tick due to uncancelled tick scheduled before we entered\ndynticks mode.\n\nThis also removes a needless clockevent write on idle ticks. Since those\nclock write are usually considered to be slow, it's a general win.\n\nChange-Id: Id416f55d0356c0f3d178e87d9821ea50d2e1ed69\nReviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Frederic Weisbecker <fweisbec@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Twisted-Kernel/S6-MM/commits/9a0d466251e28da788244f3de3de5006c335250e"},{"sha":"89f1df984ec1962334954cb484e33fae2f91e345","author":{"name":"Viresh Kumar","email":"4ca49bc1dcfdfc376d29da1eb07a3e0b3cd46daa@linaro.org"},"message":"nohz: Avoid tick's double reprogramming in highres mode\n\nIn highres mode, the tick reschedules itself unconditionally to the\nnext jiffies.\n\nHowever while this clock reprogramming is relevant when the tick is\nin periodic mode, it's not that interesting when we run in dynticks mode\nbecause irq exit is likely going to overwrite the next tick to some\nrandomly deferred future.\n\nSo lets just get rid of this tick self rescheduling in dynticks mode.\nThis way we can avoid some clockevents double write in favourable\nscenarios like when we stop the tick completely in idle while no other\nhrtimer is pending.\n\nChange-Id: I4e73da9bffbcac49789e5f279b67873f414b22a8\nSuggested-by: Frederic Weisbecker <fweisbec@gmail.com>\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Frederic Weisbecker <fweisbec@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Twisted-Kernel/S6-MM/commits/89f1df984ec1962334954cb484e33fae2f91e345"}]}
{"actor":{"display_login":"The-Sickness"}}