On 22 March 2013 20:35, Jens Axboe <axboe@xxxxxxxxx> wrote: Hi Jens, First of all, please have a look at: 1. https://lkml.org/lkml/2013/3/18/364 This is cover-letter of my mail where i have shown power savings achieved with this patchset. 2. https://lkml.org/lkml/2013/3/21/172 This is the link for discussion i had with Tejun which answers some of these questions. > 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. If the local cpu is busy or all cpus are idle then we don't migrate, and so for performance shouldn't be affected with it. > For the delayed functions, the timer is typically added on the current > CPU. This is the code that executes here: if (unlikely(cpu != WORK_CPU_UNBOUND)) add_timer_on(timer, cpu); else add_timer(timer); Clearly for queue_delayed_work() call we don't use local cpu but we use the same sched_select_non_idle_cpu() routine to give us the right 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? Correct, and we are not deciding that right now, but when the timer expires. Thanks for your feedback. -- 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
