On Sat, Sep 30, 2006 at 01:44:56AM -0700, Andrew Morton wrote:
> On Fri, 29 Sep 2006 23:58:35 -0000
> Thomas Gleixner <[email protected]> wrote:
>
> > From: Ingo Molnar <[email protected]>
> >
> > dynticks core code.
> >
> > Add idling-stats to the cpu base (to be used to optimize power
> > management decisions), add the scheduler tick and its stop/restart
> > functions, and the jiffies-update function to be called when an irq
> > context hits the idle context.
> >
>
> I worry that we're making this feature optional.
> > + /*
> > + * RCU normally depends on the timer IRQ kicking completion
> > + * in every tick. We have to do this here now:
> > + */
> > + if (rcu_pending(cpu)) {
> > + /*
> > + * We are in quiescent state, so advance callbacks:
> > + */
> > + rcu_advance_callbacks(cpu, 1);
> > + local_irq_enable(); <----------------- Here
> > + local_bh_disable();
> > + rcu_process_callbacks(0);
> > + local_bh_enable();
> > + }
> > +
> > + local_irq_restore(flags);
> > +
> > + return need_resched();
> > +}
>
> Are the RCU guys OK with this?
What prevents more RCU callbacks getting queued up by an
irq after irqs are enabled (marked Here) ? This seems racy.
The s390 implementation is correct - there we back out
if RCU is pending. Also, one call
to rcu_process_callbacks() doesn't guarantee that all
the RCUs are processed. They can be rate limited.
Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]