Messages in this thread | | | Date | Mon, 25 Sep 2006 15:49:57 +0800 | From | Aubrey <> | Subject | Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18 |
| |
On 9/25/06, Arnd Bergmann <arnd@arndb.de> wrote: > 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. >
Oh, sorry for my unclear description, any of the peripherals can be configured to wake up the core from its idled state to process the interrupt on Blackfin. I should say __if no other interrupts__ here is the timer interrupt waking up the processor every one jiffy.
I don't understand if interrupt occurs between need_resched() and the idle instruction, what will become the racy object? Can you comment it detailed? thanks.
-Aubrey - 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/
| |