Re: Efficient IPC mechanism on Linux

[Alan Cox]

On Mer, 2003-09-10 at 10:04, Luca Veraldi wrote:
> Surely, transferring bytes from a cache line to another is at zero cost
> (that is, a single clock cycle of the cache unit).

More complicated - when you move stuff you end up evicting another chunk
from the cache, you can't armwave that out of existance because you
yourself have created new eviction overhead for someone further down the
line.

> But here, how can you matematically grant that,
> using traditional IPC mechanism,
> you'll find the info you want directly in cache?

Because programs normally pass data they've touched to other apps.
Your A/B example touches the data before sending even, but your
example on receive does not which is very atypical.

> > Ok - from you rexample I couldnt tell if B then touches each byte of
> > data as well as having it appear in its address space.
> 
> It is irrilevant. The time reported in the work are the time needed
> to complete the IPC primitives.
> After a send or a receive over the channel,
> the two processes may do everything they want.
> It is not interesting for us.

Its vital to include it in the measurement of all three. Without it
your measurements are meaningless. Look at it as an engineer. IPC 
involves writing to memory, making the data appear in the other task and
then reading it. You also want to measure things like throughput of your
IPC tasks running parallel to other processes doing stuff like pure
memory bandwidth tests so you can measure the impact you have on the
system although in this case thats probably less relevant by far

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/