lkml.org 
[lkml]   [2004]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.103 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site