Re: [PATCH] tick/broadcast-hrtimer : Fix suspicious RCU usage in idle loop

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Mar 17, 2015 at 09:49:45AM +0530, Preeti U Murthy wrote:
> Ok I see your point now. Sorry about having misinterpreted it
> previously. ce_broadcast_hrtimer is not the per-cpu clock device. It is
> not a real clock device. It is a pseudo clock device, which is called
> only from the guts of the broadcast framework.
> When it is programmed, it queues a hrtimer and programs the per-cpu
> clock device. in the fashion mentioned above.
> 
> No hrtimer programming/starting/canceling will get routed through
> bc_set_next(). The broadcast framework makes use of a separate broadcast
> clock device, which is never the per-cpu clock device to wake cpus from
> idle. This device is programmed explicitly when required and not
> indirectly via timer queueing. *Only* when this broadcast clock device
> needs to reprogrammed, bc_set_next() gets called on those archs which
> *do not have a real broadcast clock device*. And the whole thing kicks
> in when cpus go idle only, not just for PowerPC but for ARM as well.

Ah, I see, tick_check_new_device() will never select it.

CLOCK_EVT_FEAT_PERCPU seems a rather pointless thing though, maybe a
remnant of something gone.

OK now it makes sense.. some of this could use a few comments, but I
suppose that's true of most things ;-)