Messages in this thread | | | From | Javier Martinez Canillas <> | Date | Thu, 1 Mar 2012 20:02:04 +0100 | Subject | Re: [PATCH 0/10] af_unix: add multicast and filtering features to AF_UNIX |
| |
On Thu, Mar 1, 2012 at 6:59 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le 1 mars 2012 08:02, Luiz Augusto von Dentz <luiz.dentz@gmail.com> a écrit : >> >> Contrary to someones believes I don't think AF_INET is that fast (e.g. >> http://scottmoonen.com/2008/04/05/a-performance-comparison-of-af_unix-with-loopback-on-linux/) >> > > Oh you mention a recent zork it seems ;) > > Are we speaking of performance problems, apart from scheduler problems > for D-Bus (each message wakeing all receivers, all receivers read and > drop message but the target) ? >
Hi Eric,
The only performance problem we are talking about is the scheduling for D-bus (context switch to the daemon for each message). With today implementation the receivers only gets messages that were sent to it but the D-bus daemon has to be wake it up for every message to he can do the routing. For multicast messages (i.e: D-bus signals) this is even worse since the daemon has to do a send() for each receiver.
> I am actually one of the few people working to improve performance on > both AF_INET and AF_UNIX parts. Just take a look at recent commits. > > Right now you can send/receive millions of udp messages per second on > your linux machine, if you figured out how to avoid process scheduler > costs. If D-Bus wants more, I highly suggest using shared memory > instead of passing messages. > --
Yes, I also thought that AF_UNIX would be more efficient than AF_INET but I was wrong. Yesterday I wrote some tests using our multicast unix socket, UDP multicast over IP on a single machine and even multicast using AF_NETLINK sockets and got very similar performance results.
The only problem is the ordering and control flow requirements for D-bus.
Best regards, Javier -- 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/
| |