On 06/02/2014 08:33 PM, Viresh Kumar wrote:
Hi,
Here goes the fourth version and its very much light weight compared to earlier versions. I hope I haven't missed any review comments here :)
More or less all patches are updated to get rid of all unrelated changes, like removing unsupported modes OR not disabling events for default cases..
So, please review them again :)
Here goes the mainline version of cover-letter:
A clockevent device should be stopped, or its events should be masked, if next event is expected at KTIME_MAX, i.e. no events are required for very long time.
This would normally happen with NO_HZ (both NO_HZ_IDLE and NO_HZ_FULL) when tick-sched timer is removed and we don't have any more timers scheduled for long.
If we don't STOP clockevent device, we are guaranteed to receive at least one spurious interrupt, as hrtimer_force_reprogram() isn't reprogramming the event device (on expires == KTIME_MAX). Depending on particular implementation of
You might want to remove the brackets around "on expires == KTIME_MAX". Its quite a while since we mentioned that this is the case we are solving, so best to mention it as a part of the main sentence.
clockevent device, this can be a fake interrupt at tick-rate.. (When driver is emulating ONESHOT over PERIODIC mode. This was observed on at least one implementation: arm_arch_timer.c).
A simple (yet hacky) solution to get this fixed could be: update hrtimer_force_reprogram() to always reprogram clockevent device and update clockevent drivers to STOP generating events (or delay it to max time), when 'expires' is set to KTIME_MAX. But the drawback here is that every clockevent driver has to be hacked for this particular case and its very easy for new ones to miss this.
However, Thomas suggested to add an optional mode: ONESHOT_STOPPED (lkml.org/lkml/2014/5/9/508) to solve this problem.
With this proposal, introducing a new ONESHOT_STOPPED mode would require the core to know whether the platform implements this mode so it could be reprogrammed later.
The core would need to know if the platform implements this mode so as to warn the callers if the mode is not implemented. They can take appropriate actions then. We will be handling the ONESHOT_STOPPED devices in the same way whether the platform implements this mode or not right? In either case we would need to reprogram the clock devices when necessary.
Regards Preeti U Murthy