Subject: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat May 12 2001 - 13:48:47 EEST
>Paul, I'm a wrong if I affirm that the same instruction/data cache
>pollution is caused by plugin/component invocation in one-process
>approach?
Yes and no.
There are two components to what Larry McVoy was writing about
there. One is the simple "cache pollution", and yes, this would happen
even in the single-process model. The other is caused by having to
invalidate the TLB when context switching. AFAIK, items left in the
cache after a TLB flush are not usable until the TLB has revalidated
them, if at all.
So, in the single process model, we get cache pollution, but if each
component doesn't fill the cache, then as we move from component to
component, there's a reasonable chance that we get to use the cache
effectively.
How would they not fill the cache? Quite possible to do with low
latency situations, since the amount of data is low for each
period. For the Hammerfall (as the current extreme case), a 64 frame
period length requires processing 6kB of input data per
period. Careful coding can probably ensure fairly effective use of the
cache in this instance. Its mostly a function of reducing the number
and size of the buffers used between components. For example, in
Ardour (on a hammerfall, with a 64 frame period), there is only one
6kB set of buffers (26 of them, each 256 bytes) used by every internal
object to process data (e.g read data from channel into a buffer and
then do some DSP on it). this one set lives in the cache very
comfortably, and means that we can have any number of internal objects
processing data without much effect on the data cache.
In the multiprocess model, each time we context switch, the fact that
all the input data is actually in the cache (for example) temporarily
becomes irrelevant while we wait for the TLB to revalidate cache
entries and/or for the cache to refill.
--p
This archive was generated by hypermail 2b28 : Sat May 12 2001 - 14:08:51 EEST