This happened for me during my NO_HZ_FULL testing on isolated CPU, but may happen otherwise as well.
When the last htimer of a CPU is cancelled (For example: for NO_HZ_FULL when expires == KTIME_MAX), we do not SHUTDOWN the event device. And because of that we will get interrupted unnecessarily on the isolated core as event device will interrupt as per the last value it is configured with.
The implementation of event device's driver may make it worse. For example: drivers/clocksource/arm_arch_timer.c disables the event device only on SHUTDOWN/UNUSED requests in set-mode. Otherwise, it will keep giving interrupts at tick interval even if hrtimer_interrupt() didn't reprogram tick (When expires == KTIME_MAX). And so we will keep getting interrupt every few milliseconds. To confirm this I added a small hack in hrtimer.c [1] and got these results [2] as soon as the CPU got isolated with NO_HZ_FULL and cpusets.
Probably the right solution to fix this is to disable the event device for such cases, i.e. expires == KTIME_MAX and restart it later when required. This will get rid of unnecessary interruption which can be avoided.
Tested over 3.15-rc4 on ARM Exynos5250 (Dual A15) board.
NOTE: Current implementation of NO_HZ_FULL has a limitation of 1 second and so we might never end up cancelling sched_timer. I was using Kevin's debug patch: https://lkml.org/lkml/2013/12/17/649, with which I am able to get expires to KTIME_MAX and so ended up cancelling hrtimer.
[1] http://pastebin.com/MhDdawVd [2] http://pastebin.com/5U5FBbTW
Viresh Kumar (2): hrtimer: reprogram event for expires=KTIME_MAX in hrtimer_force_reprogram() tick: SHUTDOWN event-dev if no events are required for KTIME_MAX
include/linux/clockchips.h | 1 + kernel/hrtimer.c | 3 +-- kernel/time/tick-oneshot.c | 14 +++++++++++++- 3 files changed, 15 insertions(+), 3 deletions(-)