Re: [RFC] Strange code in cpu_idle()

[Zwane Mwaikambo]

Hello Paul,

On Sat, 4 Dec 2004, Paul E. McKenney wrote:

> Unless idle_cpu() is busted, it seems like the above is, given the code in
> rcu_check_callbacks():
> 
> 	void rcu_check_callbacks(int cpu, int user)
> 	{
> 		if (user || 
> 		    (idle_cpu(cpu) && !in_softirq() && 
> 					hardirq_count() <= (1 << HARDIRQ_SHIFT))) {
> 			rcu_qsctr_inc(cpu);
> 			rcu_bh_qsctr_inc(cpu);
> 		} else if (!in_softirq())
> 			rcu_bh_qsctr_inc(cpu);
> 		tasklet_schedule(&per_cpu(rcu_tasklet, cpu));
> 	}
> 
> And idle_cpu() is pretty straightforward:
> 
> 	int idle_cpu(int cpu)
> 	{
> 		return cpu_curr(cpu) == cpu_rq(cpu)->idle;
> 	}
> 
> So I would say that the rcu_read_lock() in cpu_idle() is having no
> effect, because any timer interrupt from cpu_idle() will mark a
> quiescent state notwithstanding.  What am I missing here?

What about the hardirq_count check since we're coming in from the timer 
interrupt?

> Note that we really, really do want the idle loop to be an extended
> quiescent state, otherwise one gets indefinite grace periods and
> runs out of memory...

I've (hopefully) covered this in another email.

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/