Messages in this thread Patch in this message |  | | | Date | Mon, 13 Jun 2005 02:45:30 +0200 | | From | Andrea Arcangeli <> | | Subject | Re: PREEMPT_RT vs ADEOS: the numbers, part 1 |
| |
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. - 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/
|  |