--nextPart1824869.DXcXQSfxco
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

as far as I know pipe() is now much faster than socketpair(), because pipe(=
)=20
uses the zero-copy mechanism.

However there are numerous applications using socketpair() instead of two=20
pipe()s, because they need exactly _one_ fd for read/write instead of 2.

Over 180 open unix domain sockets are on my system right now.

Many of this applications could gain a speedup if only they could change to=
 a=20
different system call like epipe().

epipe() would behave like socketpair(), but internally use two pipes (one f=
or=20
each direction).

It seems so easy to do, so I'm really wondering, why it hasn't been done, y=
et?

However new system calls always have the problem of portability. Though in=
=20
this case an epipe -> socketpair fallback would work.

So perhaps a better idea would be to enhance skbuff to use the new zero-cop=
y=20
mechanism ... ?

The reason why I had the idea is that I had huge socketpair performance=20
problems, but with an old 2.4.27 kernel and a custom kernel module:

Almost 1 sec of latency!

Changing the fds provided from userspace to pipe()s did result in good=20
performance.

Might be a bug in my module though ...

cu

=46abian

PS: Please CC me as I'm not subscribed.

=2D-=20
      *** Consulting - Training - Workshops - Troubleshooting ***
   @@@ LiveCDs (Knoppix), Debian, Remote Desktop Access (FreeNX) @@@

=2D-- Fabian Franz --- www.fabian-franz.de --- consulting@fabian-franz.de

--nextPart1824869.DXcXQSfxco
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQBFFsKeI0lSH7CXz7MRAikPAJ9S2gXRlGQdZt6pyKEGQNEJMDNTJACcC1Ab
qwAL4B7I9TDAnjgEvQonzno=
=C5TJ
-----END PGP SIGNATURE-----

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