[LAD] Faster context switch

[Michael Ost]

On 11/2/10 10:06 AM, Paul Davis wrote:
> 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?
<snip>
>> 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.

I asked Alexandre Julliard, the maintainer of the Wine project, about 
the libfst approach, and thought this list might be interested in his 
response.

- Michael Ost

First message (nov 8) when asked for a read on the libfst design he 
said, "They have a wineserver and everything, they just bypass the 
preloader and initial setup. It's a variant of the Mono patch. It should 
work OK as long as both the host Linux app and the Windows DLL are 
well-behaved and don't depend on things like memory layout, switching 
stacks, signals, starting Linux threads, etc."

And here's the second message, an exchange where I (MO) asked him (AJ) 
for details about the above points:

MO: "Memory layout" - is there any risk that a DLL might see a smaller 
VM size without the preloader? We are using the /3GB switch. Would that 
be at risk?

AJ: It's not just size, but areas that are expected to be free that 
would be occupied, for instance the DLL load address, things like that.

MO: "Switching stacks" - I can't see an audio DLL switching stacks. 
Sounds like something a debugger might do...?

AJ: I know the jack library on Linux plays some strange games with the 
stack to try to reduce latency. I'd imagine an audio DLL might try to do 
stuff like that.

MO: "Signals" - seems very unlikely for a hosted audio DLL
"Starting Linux threads" - shouldn't happen from straight windows code.

AJ: These two would be potential problems in the Linux host application, 
not in the DLL.

MO: "Etc" - and what might this be? %)

AJ: I'm sure there are other things, it's really hard to predict what
unspecified code is going to do. Basically everything we do during
startup was added because something depended on it, so anything that is
bypassed is a potential problem. Whether it will be a problem in actual
use can really only be determined by testing.

MO: This is all in WINE/loader, right?

AJ: Yes, but there's a lot of init code in ntdll too, particularly 
regarding memory layout (that code will still be executed with the 
libfst patch, but it may not be able to set things up the way it wants 
to when not run at process startup).