Re: Efficient IPC mechanism on Linux

[Luca Veraldi]

> I mean for benchmarks. You compared your implementation to a very old
> linux' one. There were big changes in these areas.

The overhead implied by a memcpy() is the same, in the oder of magnitude,
***whatever*** kernel version you can develop.

If you have to send, lt's say, 3 memory pages from A to B,
using pipes you have to ***physically copy***
2 * 3 * PAGE_SIZE bytes
(firt time, sending; then receiving them. So two times).
Which evals to 8192 * 3.

Using capability, the only thing you have to do
is copying an amount of bytes that are linearly dependent
by the number of pages: so, proportional to 3.

I you want the (quite) exact amount, it is
3 * sizeof(unsigned long) + sizeof(capability)
which evals to  12 + 16 = 28.
X is not present in the equation.

I compared pipes and SYS V IPC on Linux 2.2.4 with the new mechanism
also developed over kernel 2.2.4!
The same inefficiency of the kernel support you are talking about
affet all the primitives being examined in the article. Mine, too.

So the relative results will be quite the same.

> you surely know, that it is just an implementation. The mechanisms have
> always been there, evolved from UNIX.
> That is mainly the reason for them to exists: support the applications
> which use them.
>
> Will it be possible to base existing facilities on your approach?
> SVR5 messages (msg{get,snd,rcv}), for example?
> (I have to ask, because I cannot understand the article, sorry)

Ah, ok. So let's continue to do ineffient things
only because it has always been so!

Compatibility is not a problem. Simply rewrite the write() and read() for
pipes
in order to make them do the same thing done by zc_send() and zc_receive().
Or, if you are not referring to pipes, rewrite the support level of you
anchient IPC primitives
in order to make them do the same thing done by zc_send() and zc_receive().

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/