Re: [PATCH] Remove RCU abuse in cpu_idle()

[Zwane Mwaikambo]

On Mon, 20 Dec 2004, Nick Piggin wrote:

> This thread can possibly be stalled forever if there is a CPU hog
> running, right?

Yep.

> In which case, you will want to use ssleep rather than a busy loop.

Well ssleep essentially does the same thing as the schedule_timeout.

> Another alternative may be to use more complex logic to detect that a
> CPU is not in the idle loop at all. In that case, a simple cpu_relax
> type spin loop should be OK, because the synchronisation would be
> achieved very quickly.

I considered checking whether the cpu is in the idle thread or not but 
wouldn't that require locking runqueues? Something like;

pm_idle = new_value;
wmb();
busy_map = cpu_online_map;
for_each_online_cpu(cpu) {
	runqueue_t *rq = cpu_rq(cpu);
	spin_lock_irq(&rq->lock);
	if (rq->curr != rq->idle)
		cpu_clear(cpu, busy_map);
	spin_unlock_irq(&rq->lock);
}

cpu_idle_map = busy_map;
wmb();

while (!cpus_empty(cpu_idle_map)) {
	cpus_and(cpu_idle_map, cpu_idle_map, cpu_online_map);
	ssleep(1);
}

Hmm then again, i think we could get away with doing an unlocked compare 
on the rq->curr and rq->idle since we've written back pm_idle and reading 
a stale rq->curr which isn't equal to rq->idle means that the remote 
processor should also have the new pm_idle. I'm still not convinced that 
it deserves this much complexity, this is a rarely carried out operation 
and usually at boottime or shutdown.

Thanks,
	Zwane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/