Re: PREEMPT_RT vs ADEOS: the numbers, part 1

[Andrea Arcangeli <andrea@suse.de>]

On Sun, Jun 12, 2005 at 10:59:02PM +0200, Ingo Molnar wrote:
> if you want to measure hw-interrupt delays then under PREEMPT_RT you'll 
> need to use an SA_NODELAY interrupt handler. (which is a PREEMPT_RT 
> specific flag) If you use normal request_irq() or some parport driver 
> then the driver function will run in an interrupt thread and what you 
> are measuring is not interrupt latency but rescheduling latency.

Karim, just in case you're not very familiar with parport, this should
do the trick:

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2286,7 +2286,7 @@ struct parport *parport_pc_probe_port (u
 	}
 	if (p->irq != PARPORT_IRQ_NONE) {
 		if (request_irq (p->irq, parport_pc_interrupt,
-				 0, p->name, p)) {
+				 SA_NODELAY, p->name, p)) {
 			printk (KERN_WARNING "%s: irq %d in use, "
 				"resorting to polled operation\n",
 				p->name, p->irq);

Unless I'm missing something, this mode is only valid if coding the RT
code in the hardirq handler, which didn't seem the main benefit of
preempt-RT to me, but it's still an interesting basic benchmark,
especially now that local_irq_disable is "soft".

But I'd be nice to also measure the performance of the non-RT part of
the workload, just a suggestion if you have time.

With above patch applied my crystal ball expects preempt-RT to perform
much closer to adeos, but with the difference that the non-RT part of
the system will still get the burden of the added complexity that adeos
won't have.

Thanks.