On Mon, Mar 18 2013, Viresh Kumar wrote: > block layer uses workqueues for multiple purposes. There is no real dependency > of scheduling these on the cpu which scheduled them. > > On a idle system, it is observed that and idle cpu wakes up many times just to > service this work. It would be better if we can schedule it on a cpu which isn't > idle to save on power. > > By idle cpu (from scheduler's perspective) we mean: > - Current task is idle task > - nr_running == 0 > - wake_list is empty > > This patch replaces schedule_work() and queue_[delayed_]work() with > queue_[delayed_]work_on_any_cpu() siblings. > > These routines would look for the closest (via scheduling domains) non-idle cpu > (non-idle from schedulers perspective). If the current cpu is not idle or all > cpus are idle, work will be scheduled on local cpu. What are the performance implications of this? From that perspective, scheduling on a local core is the better choice. Hopefully it's already running on the local socket of the device, keeping it on that node would be preferable. For the delayed functions, the timer is typically added on the current CPU. It's hard to know what the state of idleness of CPUs would be when the delay has expired. How are you handling this? I can see the win from a power consumption point of view, but it quickly gets a little more complicated than that. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
