>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: [email protected] WWW: http://www.keba.com
On Apr 11, 2005 1:38 PM, kus Kusche Klaus <[email protected]> wrote:
> So the question is, what exactly is the IDE priority?
> Is the PIO transfer done in the IRQ handler or in a bh?
in the IRQ handler
I handled this issue by precaching all my files (15MB),
from my readonly root filesystem.
find / -type f |
grep -v ^/boot | #kernel is > 1MB and never read so don't put in cache
while read file; do
dd bs=32k if="$file" of=/dev/null 2>/dev/null
done
P?draig.