2012/12/22 Steven Rostedt <rost...@goodmis.org>: > The idle_balance() code is called to do task load balancing just before > going to idle. This makes sense as the CPU is about to sleep anyway. > But currently it's called in the middle of the scheduler and in a place > that must have interrupts disabled. That means, while the load balancing > is going on, if a task wakes up on this CPU, it wont get to run while > the interrupts are disabled. The idle task doing the balancing will be > clueless about it. > > There's no real reason that the idle_balance() needs to be called in the > middle of schedule anyway. The only benefit is that if a task is pulled > to this CPU, it can be scheduled without the need to schedule the idle > task. But load balancing and migrating the task makes a switch to idle > and back negligible.
This cleanup looks nice as it does not only let us enable interrupts there but also debloats a bit the schedule() code from idle specific code. So it would be a pity if the optimization that goes away with your cleanup has any measurable impact. Is there any sensible benchmark that can be run against this patch? Something that may involve a lot of back and forth to idle with some bunch of tasks running around on other CPUs? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/