Re: Efficient IPC mechanism on Linux

["Luca Veraldi" <luca.veraldi@katamail.com>]

> sorry for the self followup, but I just read another message where you
> mention 2.2, if that was for 2.2 the locking was the ok.

Oh, good. I was already going to put my head under sand. :-)

I'm not so expert about the kernel. I've just read [ORLL]
and some bits of the kernel sources.
So, error in the codes are not so strange.

But, it's better now that you know we are talking about version 2.2...

I'm glad to hear that locking are ok.

You say:

> in terms of design as far as I can tell the most efficient way to do
> message passing is not pass the data through the kernel at all (no
> matter if you intend to copy it or not), and to simply use futex on top
> of shm to synchronize/wakeup the access.  If we want to make an API
> widespread, that should be simply an userspace library only.
>
> It's very inefficient to mangle pagetables and flush the tlb in a flood
> like you're doing (or better like you should do), when you can keep the

I guess futex are some kind of semaphore flavour under linux 2.4/2.6.
However, you need to use SYS V shared memory in any case.
Tests for SYS V shared memory are included in the web page
(even though using SYS V semaphores).

I don't think, reading the numbers, that managing pagetables "is very
inefficient".
I think very inefficient are SYS V semaphore orethe double-copying channel
you call a pipe.

> there's also an obvious DoS that is trivial to generate by locking in
> ram some 64G of ram with ecbm_create_capability() see the for(count=0;
> count<pages; ++count) atomic_inc (btw, you should use get_page, and all
> the operations like LockPage to play with pages).

As I say in the web page,

 having all the pages locked in memory is not a necessary condition
for the applicability of communication mechanisms based on capabilities.
Simply, it make it easier to write the code and does not make me crazy
with the Linux swapping system.

Bye bye,
Luca