On 7 May 2014 15:38, Thomas Gleixner tglx@linutronix.de wrote:
On Wed, 9 Apr 2014, Viresh Kumar wrote:
This patch tries to fix this by registering cpu notifiers from clocksource core, only when we start clocksource-watchdog. And if on the CPU_DEAD notification it is found that dying CPU was the CPU on which this timer is queued on, then it is removed from that CPU and queued to next CPU.
Gah, no. We realy don't want more notifier crap.
Agreed, and could have used the generic ones, probably.
It's perfectly fine for the watchdog timer to be moved around on cpu down.
Functionally? Yes. Then handler doesn't have any CPU specific stuff to do here and so queuing it on any cpu is fine.
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]?
-- viresh