[lkml]   [2005]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PREEMPT_RT vs ADEOS: the numbers, part 1

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

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

Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits || || 1-866-677-4546
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 03:13    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean