[lkml]   [2005]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-06-13 02:49    [W:0.104 / U:4.956 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site