Re: Efficient IPC mechanism on Linux

[Luca Veraldi]

> The question (for smaller messages) is whether this is a win or not.
> While the data fits in L1 cache the copy is close to free compared
> with context switching and TLB overhead

I can answer for messages of 512 bytes (that I consider small).
This is the smallest case considered in the work.

Completion times in this case are reported in graphs:
you have the time of write() on pipe,
of SYS V shmget() and of new primitives.
It's easy to compare numbers and to say if it is "a win or not".

Surely, transferring bytes from a cache line to another is at zero cost
(that is, a single clock cycle of the cache unit).
But here, how can you matematically grant that,
using traditional IPC mechanism,
you'll find the info you want directly in cache?
This is quite far from being realistic.

In real world, what happens is that copying a page memory
raises many cache faults... at least, more that copying a capability
structure
(16 bytes long, as reported in the article).

Of course, if you want to send a single int,
probably you don't have any reason to use capability.
That's sure.

> 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.

Bye,
Luca

-
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/