Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Sat May 12 2001 - 20:11:23 EEST
Paul Davis wrote:
>
> >> what is this program for? you're using multiple threads. i haven't
> >> seen anyone suggest this. it has neither the benefits of the
> >> multiprocess case nor the single-threaded case. i don't understand.
> >
> >It's a program to measure the actual cost of context switch (that AFAIK
> >is equal for different thread or different processes). The same program
> >may be written with shm and fork.
>
> abramo, do you know who larry mcvoy is, or how much work (and money)
> went into lat_ctx? if you want to measure the cost of a context
> switch, then lat_ctx is the way to do it.
"Proof by intimidation"? Nice example...
Only I think you're more convincing when you argument your statement ;-)
Yes, I mainly know Larry as the author of BitKeeper and for its
contributes to Linux kernel.
> i haven't run your program, so i don't know about the context switch
> time being the same. i doubt it. and besides, we're not interested in
> just context switch time, its "time from sending a message to when the
> receiver is running".
Perhaps you want to *read* my program, I think it is an accurate enough
simulation of what happens with both models.
Then I expect it to be more accurate than lat_ctx wrt our specific
problem, because I've written it trying to model that.
Also I'm not computing a latency but a cost difference between two
solution, I think it's a very different things.
> >However I cannot believe you don't see the benefits of a multithreaded
> >approach:
> >- big improvement for components that can run in parallel on SMP
> >machines
>
> nobody wants to even get close to this area right now. this is too
> complex and the tradeoffs are very hard to measure and be sure about.
> the number of systems where NCPU's is greater than 2 is extremely
> small, and i don't believe that the dual systems are best used in this
> way if an excellent user experience is the goal.
The model you have in your mind need to be trashed on SMP because its
lack of scalability? It does not seems a good idea indeed. It's like to
write a program with Y2K bug in 1998.
Note that I don't suggest to implement that, but to consider it in the
model.
>
> >- greater crash safety
>
> what? threads don't provide any crash safety. if one thread crashes,
> so does the process; if one thread does a pointer walk, it can walk
> all over the memory used by other threads.
There are many causes of crash:
- segmentation fault
- component hang
- etc.
multi threaded approach may be useful on some of them:
- component hang
- segmentation fault involving corruption of a limited area
- etc.
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Sat May 12 2001 - 20:26:59 EEST