Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat May 12 2001 - 23:51:26 EEST
>> 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.
lmbench was funded by SGI and Sun. its a major work of benchmarking
for Unix-type operating systems. it handles subtleties that i would
never have even thought of before i read the code.
>Perhaps you want to *read* my program,
I did. first of all, you've "polluted" the cache by running both
examples in the same process. and then ...
> I think it is an accurate enough
>simulation of what happens with both models.
Abramo! Nobody in this discussion has ever suggested a multithreaded
solution. the two discussion points were a multiprocess solution and a
single-threaded solution. the second part of your program models
something that wasn't being discussed.
>> 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.
Please don't put words in my mouth. I'm not suggesting we ignore
SMP. I'm pointing out that an implementation that supports parallelism
involves many, many more issues than have been raised here, and all of
which need very, very careful thought out.
>Note that I don't suggest to implement that, but to consider it in the
>model.
no, its not part of the model. it would be an additional optimization
of the model for certain systems. how well interthread communication
works is an important factor in deciding how much to parallelize, but
its not part of a single-threaded or multiprocess model.
>> 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.
wrong on both counts. it doesn't protect against component hang,
because components can still hang, and there are no mechanisms offered
by the OS to detect this before an xrun has occured; it doesn't
protect again segfaults because there is no way to know what memory
has been corrupted.
--p
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 00:06:13 EEST