Messages in this thread | | | Date | Sun, 19 Dec 2004 18:44:26 -0700 (MST) | From | Zwane Mwaikambo <> | Subject | Re: [PATCH] Remove RCU abuse in cpu_idle() |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |