Re: [PATCH V2] clocksource: register cpu notifier to remove timer from dying CPU

[Thomas Gleixner]

On Wed, 7 May 2014, Viresh Kumar wrote:
> On 7 May 2014 15:38, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > And the timer itself is not pinned at all. add_timer_on() does
> > not set the pinned bit.
> 
> The perception I had is this:
> - mod_timer() is a more complicated form of add_timer() as it has to
> tackle with migration and removal of timers as well. Otherwise they
> should work in similar way.
> - There is no PINNED bit which can be set, its just a parameter to
> __mod_timer() to decide which CPU the timer should fire on.
> - And by the 'name add_timer_on()', we must guarantee that timer
> fires on the CPU its being added to, otherwise it may break things
> for many. There might be users which want to run the handler
> on a particular CPU due to some CPU-specific stuff they want to do.
> And have used add_timer_on()...
> 
> But looking at your reply, it looks that add_timer_on() doesn't
> guarantee that timer would fire on the CPU mentioned? Is that the
> case for mod_timer_pinned() as well ?
> 
> And if that's the case what do we want should we do with these
> timers (i.e. ones added with add_timer_on or mod_timer_pinned)
> when we try to quiesce a cpu using cpuset.quiesce [1]?

There is no general rule to that. The timers which are added to be per
cpu are the critical ones. But there a lots of other use cases like
the watchdog which do not care on which cpu they actually fire. They
prefer to fire on the one they were armed on.

We have no way to distinguish that right now and I still need to find
a few free cycles to finish the design of the timer_list
replacement. I keep that in mind.

Thanks,

	tglx
--
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/