Re: PREEMPT_RT vs ADEOS: the numbers, part 1

[Karim Yaghmour <karim@opersys.com>]

Andrea Arcangeli wrote:
> 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);

Thanks for the patch. However, we actually wrote our own driver requesting
the parport int instead of using the one in Linux. We just wanted to
really customize the driver in as much as possible for benchmarking
purposes.

> 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.

We'll be redoing some of the tests, and we'll keep you posted on
the results.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 1-866-677-4546
-
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/