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

[Nick Piggin]

On Sun, 2004-12-19 at 18:44 -0700, Zwane Mwaikambo wrote:
> 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.
> 

Yes - so long as you set ->state when using 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.
> 

Hmm, yeah it is fairly complex, now that you've expanded on my
handwaving!

I think you are right about not requiring locking, so long as you
have the appropriate memory barriers in place... but it's probably
not worth the effort, as you say.

Nick


-
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/