Re: Efficient IPC mechanism on Linux

[Luca Veraldi]

> > Probably, it is worse the case of copying a memory page,
> > because you have to hold some global lock all the time.
> > This is deadly in an SMP environment,
>
> You don't need a global lock to copy memory.

See sources. You neek to lock_kernel() for a great amount of instructions
like any nother kernel function.

There are kernel locks all around in sources.
So don't come here and talk about locking ineffiency.
Because scarse scalability of Linux on multiprocessor
is a reality nobody can hide.

With or without my primitives.

> One thing I do agree with you on is the API aspect - and that is
> problematic. The current API leaves data also owned by the source.
> If I write "fred" down a pipe I still own the "fred" bits.

Even with my API. Data doesn't disapper magically
from the sender logical address space.

Also, with minor changes, you can use my primitives
to implement a one-copy channel, if shared memory among processes
sounds to you as a blasfemy.

Always better than two-fase-copying current pipe implementation.

> The
> method you propose was added long ago go to Solaris (see "doors") and
> its not exactly the most used interface even there.

Sincerely, I COMPLETELY DON'T CARE.
If it is used or not, it's completely irrilevant, when valueing performance.

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