> One of the ways of looking at it is, as we begin to > consolidate, using range timers and migrating all timers to > lesser number of CPUs would make a whole lot of sense.> > As far as the scheduler making those decisions is concerned, > my concern is that the load balancing is a continuous process > and timers don't necessarily work that way. I'd put my neck > out and say that irqbalance, range timers and timer migration > should all belong to user space. irqbalance and range timers > do, so should timer migration.

As i said it my first reply, IRQ migration is special because they are not kernel-internal objects, they come externally so there's a lot of user-space enumeration, policy and other steps involved. Furthermore, IRQs are migrated in a 'slow' fashion.

Timers on the other hand are fast entities tied to _tasks_ primarily, not external entities. Hence they should migrate according to the CPU where the activities of the system concentrates - i.e. where tasks are running.

Another thing: do you argue for the existing timer-migration code we have in mod_timer() to move to user-space too? It isnt a consistent argument to push 'some' of it to user-space, and some of it in kernel-space.