Re: WAIT vs. tickless kernel

[Ralf Baechle <ralf@linux-mips.org>]

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