On Fri, Jul 18, 2014 at 01:59:06PM +0100, Jonathan Davies wrote: > The current implementation of idle_cpu only considers tasks that might be in > the > CPU's runqueue. If there's nothing in the specified CPU's runqueue, it will > return 1. But if the CPU is doing work in the softirq context, it is wrong for > idle_cpu to return 1. This patch makes it return 0. > > I observed this to be a problem with a device driver kicking a kthread by > executing wake_up from softirq context. The Completely Fair Scheduler's > select_task_rq_fair was looking for an "idle sibling" of the CPU executing it > by > calling select_idle_sibling, passing the executing CPU as the 'target' > parameter. The first thing that select_idle_sibling does is to check whether > the > 'target' CPU is idle, using idle_cpu, and to return that CPU if so. Despite > the > executing CPU being busy in softirq context, idle_cpu was returning 1, meaning > that the scheduler would consistently try to run the kthread on the same CPU > as > the kick came from. Given that the softirq work was on-going, this led to a > multi-millisecond delay before the scheduler eventually realised it should > migrate the kthread to a different CPU.
If your softirq takes _that_ long its broken anyhow. > A solution to this problem would be to make idle_cpu return 0 when the CPU is > running in softirq context. I haven't got a patch for that because I couldn't > find an easy way of querying whether an arbitrary CPU is doing this. (Perhaps > I > should look at the per-CPU softirq_work_list[]...?) in_serving_softirq()? > Instead, the following patch is a partial solution, only handling the case > when > the currently-executing CPU is in softirq context. This was sufficient to > solve > the problem I observed. NAK, IRQ and SoftIRQ are outside of what the scheduler can control, so for its purpose the CPU is indeed idle. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
