Re: [linux-audio-dev] Re: costs of IPC

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Paul Davis (pbd_AT_Op.Net)
Date: Sun May 13 2001 - 19:15:27 EEST


>Would you bet some money with me that if divide the two part I get the
>very same results?

US$0.05

>I repeat myself: it's a way to compute the extra cost to have multiple
>process (thread implementation in linux is done with processes as you
>already know)

NO, ITS NOT!

Its done with the clone(2) call, which happens to be the basis of
fork(2) as well as pthread_create(3). But the options to clone used by
pthread_create() mean that every new kernel thread uses the same
address space as the parent, meaning that context switches between two
threads in the same process does not incur a TLB flush. a kernel
thread is not a process when viewed from the perspective of the VM
system and its cache/TLB interactions.

>I've written this small program to have some reliable numbers to use for
>design decision.

What design? You've got numbers for a design that has even been
discussed here.

>"Before an xrun has occured"??? Of course not... I was thinking to
>something far less ambitious. A component does not answer any more? We
>disable it/kill it/restart it. The one process model imply that all the
>application need to be restarted.

How do you propose to detect that a component has not answered? Think
about it for a little while, and I think you'll see that the way you
would do this with a multithreaded app is not very different than the
way you'd do it with a multiprocess design.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun May 13 2001 - 19:35:26 EEST