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

[Peter Zijlstra]

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 ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/