[LAD] Faster context switch

[Paul Davis]

On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost <most at museresearch.com> wrote:
> Hi list,
>
> I am seeing what appears to be a 4 - 7 usec context switch time on a 3 GHz
> Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66 GHz
> Atom. Is that reasonable? Does anyone have any tips on how to speed that up,
> if possible?

context switch time is a combination of:

    (a) instructions executed to implement the switch
    (b) processor stalling after the switch due to TLB invalidation (the virtual
           address mapping has changed)

you can't easily measure (b) but its value depends in part on the
working set size of the tasks on each side of the switch.

(a) is going to be directly linear with the processor Hz, and so your
results, which show that a processor which is roughly half the speed
takes roughly twice as a long is entirely expected.

> I believe this is roughly the approach taken by other linux audio apps to
> host Wine vsts. And is also something like how Jack does IPC.

well, yes and no. Its similar to the approach used by dssi-vst and
kjetil's original vstserver. its not how FST works.

> But it takes about 4-7 usecs on the faster machine to signal another app and
> have it wake up again. I assume this is the time needed for a context
> switch.
>
> Since this has to happen twice per buffer, at a 32 sample buffer size and
> with 10 VSTs, overhead accounts for about 14% of the CPU. On the slower Atom
> machine, it would account for 33% of the CPU.

you can't reduce context switch times. the code involved is in the kernel.

it is precisely this problem that led to FST, and the more general use
of FST by ardour (for example) where rather than going back and forth
between wine and the linux app, the linux app becomes a wine process
itself, and everything is in-process.