20 Jul
2004
20 Jul
'04
5:25 a.m.
* Lee Revell <rlrevell(a)joe-job.com> wrote:
But the current behavior only causes latency problems
for an IDE
system, so if this were made runtime-tunable then it would only be an
issue for SATA, right? This would cover 99.9% of audio users, who
would gladly trade some disk throughput for lower latency. You can
record a *lot* of tracks with even a few MB/s of disk throughput.
it's an issue for all block IO drivers that do IO completions from IRQ
context and that can do DMA - i.e. every block IO hardware that uses
interrupts. This includes SCSI too. In fact for SCSI it's a norm to have
tagged queueing active so there the latencies ought to be even higher
(although i havent measured this). IDE/PATA's limitation in this regard
limits latencies as well.
being able to control the max size of sg-tables and the max # of
outstanding commands per IRQ source [this later should already be
possible via driver options] should enable us to control the maximum
hardirq latency introduced by block IO.
(if the hardware & disk is fast enough, or you use a high # of
controllers and disks then you could still overload your system with a
stream of interrupts and cause unbound scheduling latencies - but this
is a separate problem.)
Ingo