Re: [LAD] Faster context switch

On 11/2/10 10:06 AM, Paul Davis wrote:
> On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost<most@email-addr-hidden> 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).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Nov 10 20:15:03 2010