RT 45-01: CF Card read: High latency?

[kus Kusche Klaus]

>From the three sources of multi-millisecond latency in my experiments
(console messages to dead serial console, USB I/O, CF Card bulk read), 
I've analyzed one:

The latency of around 70 milliseconds in low-priority RT processes
when running a "dd if=/dev/hda of=/dev/null" in parallel (where hda
is a CF card) is due to readahead.

Two indications for that:
* Per default, maximum readahead is 128 KB. 70 ms is exactly the time
needed to transfer 128 KB 
(our CF cards have a sustained transfer rate of 1800 KB/sec).
* If the readahead constants in the kernel are changed,
the observed latencies scale almost linearly.

So obviously:
* The PIO mode IDE transfers keep the CPU 100 % busy.
* No other processes get scheduled between the data transfer of
individual "sectors", i.e. there are no holes between the IDE 
interrupts.

However, there is no need to change the readahead mechanism,
because even the transfer of a single sector would exceed our
latency requirements. So we either need to switch to DMA (which we
can't in the short term), or run the time-critical tasks above IDE 
priority. 

So the question is, what exactly is the IDE priority?
Is the PIO transfer done in the IRQ handler or in a bh?

-- 
Klaus Kusche                 (Software Development - Control Systems)
KEBA AG             Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120                 Fax: +43 / 732 / 7090-6301
E-Mail: kus@xxxxxxxx                                WWW: www.keba.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/