Messages in this thread | | | Date | Mon, 6 Dec 2004 02:47:11 -0700 (MST) | From | Zwane Mwaikambo <> | Subject | Re: [RFC] Strange code in cpu_idle() |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |