Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Anders Torger (torger_AT_ludd.luth.se)
Date: Sun May 13 2001 - 01:16:55 EEST
On Sunday 13 May 2001 03:11, you wrote:
> On Sat, 12 May 2001, Abramo Bagnara wrote:
> > This thread is becoming more and more instructive ;-)
>
> Yes indeed! But I think you've forgotten one aspect of this IPC issue: how
> the audio system (= referring to the whole single/multi-threaded/process
> system) behaves under heavy load?
>
> As I've mentioned in my earlier message today, multiple threads means
> multiple deadlines. Even if we assume IPC has zero cost, scheduling is
> still a problem. If you have 30 threads/processes participating in the
> audio processing, that means each of those threads must get enough
> processor time during the <5ms timeframe we have...
>
> Now I'm not saying it's impossible to have those 30 threads. It might be
> that by using user-space threads (or something else that gives you control
> over thread scheduling) might enable you to solve the problem. I've
> understood that gstreamer does something along these lines. But you can't
> deny that it's much easier and simpler to solve the problem by running one
> thread with sched_fifo priority...
For portability reasons, I think one should keep to very few threads, or
multiple processes. Linux has *no* userspace threads (at least not standard),
FreeBSD had until recently *only* userspace threads, thus no performance
improvement on an SMP machine. The best would be using few multiple processes
(ideally as many as there are processors in the host machine).
I don't know if there is any performance difference between running two
separate processes on two processors or having threads instead, looking at
the address space issue. I'm not a hardware expert, my guess is that the
processors keep own TLBs and caches and thus would not gain from having the
same virtual address space.
/Anders Torger
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 01:35:12 EEST