RE: epoll_wait() performance

[David Laight]

From: Willem de Bruijn
> Sent: 27 November 2019 19:48
...
> Are the latest numbers with CONFIG_HARDENED_USERCOPY?

According to /boot/config-`uname -r` it is enabled on my system.
I suspect it has a measurable effect on these tests.

> I assume that the poll() after recv() is non-blocking. If using
> recvmsg, that extra syscall could be avoided by implementing a cmsg
> inq hint for udp sockets analogous to TCP_CM_INQ/tcp_inq_hint.

All the poll() calls are non-blocking.
The first poll() has all the sockets in it.
The second poll() only those that returned data the first time around.
The code then sleeps elsewhere for the rest of the 10ms interval.
(Actually the polls are done in blocks of 64, filling up the pfd[] each time.)

This avoids the problem of repeatedly setting up and tearing down the
per-fd data for poll().

> More outlandish would be to abuse the mmsghdr->msg_len field to pass
> file descriptors and amortize the kernel page-table isolation cost
> across sockets. Blocking semantics would be weird, for starters.

It would be better to allow a single UDP socket be bound to multiple ports.
And then use the cmsg data to sort out the actual destination port.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)