Is It Efficient to Use Epoll with Devices (/Dev/Event/...)

Syscall overhead

Syscalls take at least 1-2 microseconds on most modern machines just for the syscall overhead, and much more time if they're doing anything complex that could block or sleep. Expect at least 20 microseconds and up to the order of milliseconds for IO. Compare this with a tiny function call or macro that reads a byte from a userspace buffer, which is likely to complete in a matter of nanoseconds (maybe 200 ns on a bad day).

System calls overhead

For example, if we consider getpid(), when a system call is made to getpid() my guess is that if the control is currently in the child process then a context switching has to be made to enter the parent process to get the pid.

No context switch to the child process should be necessary here — the kernel should have all of the necessary data available to itself. In most cases, the kernel will only switch contexts to a userspace process in the scheduler, or when returning from a system call.

Also when getpid() is called, there will be some metadata transfer across the user-space boundary and enters and exits the kernel. So will the constant switching between user space and kernel also cause some overhead?

Yes, if getpid() was being called often, the overhead would certainly build up. There are some approaches available which can avoid this overhead for simple "getter" system calls like getpid() and gettimeofday(); one such approach which was at one point used under Linux was to store the (known) result of the system call in a special memory page. (This mechanism was known as vsyscall.)

epoll/non blocking event driven IO

Your assumption is wrong: there still is a permanent receiver on the server side.

Using epoll, select or plain blocking read/writes doesn't change anything on the networking side of things. There still is a persistent TCP session (in the case you state). The server process still has a file descriptor open on that connection.

epoll is "just" an API that allows the kernel to signal that there is stuff to do on that connection in an efficient, asynchronous manner.

---

Related Topics