On Wed, 7 May 2014, Viresh Kumar wrote:
On 7 May 2014 15:38, Thomas Gleixner tglx@linutronix.de 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