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

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