path: root/Kbuild
diff options
authorPeter Zijlstra <>2015-05-14 12:23:11 +0200
committerThomas Gleixner <>2015-05-18 17:17:42 +0200
commit4cfafd3082afc707653aeb82e9f8e7b596fbbfd6 (patch)
tree8c3abec0535288f2b27bbae7bcedda5a458a6aba /Kbuild
parentc78c881824cc3354c0518c0d21febe04ffc69638 (diff)
sched,perf: Fix periodic timers
In the below two commits (see Fixes) we have periodic timers that can stop themselves when they're no longer required, but need to be (re)-started when their idle condition changes. Further complications is that we want the timer handler to always do the forward such that it will always correctly deal with the overruns, and we do not want to race such that the handler has already decided to stop, but the (external) restart sees the timer still active and we end up with a 'lost' timer. The problem with the current code is that the re-start can come before the callback does the forward, at which point the forward from the callback will WARN about forwarding an enqueued timer. Now, conceptually its easy to detect if you're before or after the fwd by comparing the expiration time against the current time. Of course, that's expensive (and racy) because we don't have the current time. Alternatively one could cache this state inside the timer, but then everybody pays the overhead of maintaining this extra state, and that is undesired. The only other option that I could see is the external timer_active variable, which I tried to kill before. I would love a nicer interface for this seemingly simple 'problem' but alas. Fixes: 272325c4821f ("perf: Fix mux_interval hrtimer wreckage") Fixes: 77a4d1a1b9a1 ("sched: Cleanup bandwidth timers") Cc: Cc: Cc: Cc: Cc: Cc: Cc: Sasha Levin <> Signed-off-by: Peter Zijlstra (Intel) <> Link:
Diffstat (limited to 'Kbuild')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud