On Sunday 24 September 2006 05:35, Aubrey wrote:
> > This looks racy. What if you get an interrupt after testing need_resched()
> > but before the idle instruction?
> >
> > Normally, this should look like
> >
> > while(!need_resched()) {
> > local_irq_disable();
> > if (!need_resched())
> > asm volatile("idle");
> > local_irq_enable();
> > }
> >
> > Of course that only works if your idle instruction wakes up on pending
> > interrupts.
>
>
> No, that doesn't work on blackfin. Blackfin need interrupt(here is
> timer interrupt) to wake up the core from IDLE mode. Once you disable
> the interrupt, the core will sleep forever.
Ok, then this is something you should take back as feedback to your
CPU designers. With the behavior you describe, the interrupt latency
(until the point where an application runs) can be up to one jiffy
longer than it should be, which is unacceptable for many real-time
users.
Worse, it means that you can not use the CONFIG_NO_IDLE_HZ option in the
future, because you have no way to guarantee that you ever wake up from
idle if you hit the race.
Arnd <><
-
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]
