On Thu, Nov 01, 2007 at 12:49:06AM +0900, Atsushi Nemoto wrote: > On some CPUs, there is a small window in the idle task which might > cause a large latency to wakeup a process. > > http://www.linux-mips.org/archives/linux-mips/2005-11/msg00114.html > > This can be avoided on some CPUs which can use xxx_wait_irqoff(), but > still there are many CPUs out of luck. > > And now we have dyntick/tickless kernel. On tickless kernel the > problem might become more serious. We cannot know the worst latency > time. Theoretically a task can lose wakeup-event forever. > > Of course "nowait" kernel option will help, but are there any other > good solutions? > > Just an idea: If we put an WAIT in hazard area of the MTC0 which > enables interrupts, can we accomplish something like > atomic-test-and-wait operation? > > void r4k_wait_bulletproof(void) > { > local_irq_disable(); > if (!need_resched()) > __asm__( > " .set push \n" > " .set mips3 \n" > " .set noat \n" > " .align 4 \n" /* avoid stall on wait */ > " mfc0 $1, $12 \n" > " ori $1, 1 \n" > " mtc0 $1, $12 \n" > " wait \n" > " xori $1, 1 \n" > " mtc0 $1, $12 \n" > " .set pop \n"); > local_irq_enable(); > } > > If this work as expected? Comments from pipeline gurus are welcome ;) This one is definately playing with the fire. Or alternatively requires detailed knowledge of the pipeline and pipelines tend to change. MIPS Technologies does regular maintenance releases of its cores which also add features and may change the pipelines in subtle way that may break something like this. The only safe but ugly workaround is to change the return from exception code to detect if the EPC is in the range startin from the condition check in the idle loop to including the WAIT instruction and if so to patch the EPC to resume execution at the condition check or the instruction following the WAIT. Ralf
