Re: [PATCH] Remove RCU abuse in cpu_idle()
From: Zwane Mwaikambo
Date: Sun Dec 19 2004 - 20:45:47 EST
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/