[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Lee Revell]

On Tue, 2004-07-20 at 02:12, Ingo Molnar wrote:
> * Lee Revell <rlrevell at joe-job.com> wrote:
> 
> > Does this scale in a linear fashion with respect to CPU speed?  You
> > mentioned you were testing on a 2Ghz machine, does 700 usecs on that
> > translate to 2800 usecs on a 500Mhz box?
> 
> given that this particular latency is dominated by cachemisses the DRAM
> latency controls it too which is independent of CPU MHz. Wrt. cachemiss
> costs, newer CPUs typically have twice the L2-cache line size (so it
> takes more bus cycles to fetch it) - the improvements in bandwidth of
> fetching a single line should offset most of this. DRAM latencies didnt
> improve much in the past 10 years so that's almost a constant between a
> 500MHz/100MHz(system-bus) vs. 2GHz/400MHz system. So i'd guesstimate a
> 500 MHz box to do somewhere around 1000-1500 usecs.
> 

The particular system I am working with is a Via EPIA M-6000, which is
quite new but has a 600Mhz CPU due to it being fanless.  I would imagine
this would put it closer to a 'modern system' in this regard, as it uses
DDR266.

> > How much I/O do you allow to be in flight at once?  It seems like by
> > decreasing the maximum size of I/O that you handle in one interrupt
> > you could improve this quite a bit.  Disk throughput is good enough,
> > anyone in the real world who would feel a 10% hit would just throw
> > hardware at the problem.
> 
> i'm not sure whether this particular value (max # of sg-entries per IO
> op) is runtime tunable. Jens? Might make sense to enable elvtune-alike
> tunability of this value.

Yes, this would be a nice improvement.

> 
> limiting the in-flight IO will only work with IDE/PATA that doesnt have
> multiple commands in flight for a given disk. SATA and SCSI handles
> multiple command completions per IRQ invocation so limiting the size of
> a single IO op has less effect there.
> 

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.

Lee