0

I'm reading the source code of libevent,and when it needs to call epoll_create,it uses syscall insteaded.

int epoll_create(int size)
{
     return (syscall(__NR_epoll_create, size));
}

Will the latter case give a perfomance improvement?

rpbear
  • 640
  • 7
  • 15

2 Answers2

2

syscall() is a generic function for performing system calls. It allows system calls to be performed even if the current C library is older than the running kernel and therefore does not support all of the system calls that may be available.

On Linux, epoll_create() is a system call, rather than a library function. Considering the cost of switching from userspace to kernelspace and back, as well as the cost of the call itself, any overhead that is associated with using the variadic syscall() caller over a more specific wrapper is probably negligible, if it exists at all.

The main problems with syscall() have to do more with its programming interface than with its performance:

  1. There is no type safety at all - if the system call expects a char * and the programmer supplies a char, chances are that the call will not work as expected. The compiler is unable to prevent such mistakes.

  2. It presents the underlying kernel interface with no modifications, which is often not very suitable for direct use in user applications.

On the other hand, it does not depend on libc being aware and having a wrapper for the system call in question, which is an advantage from a compatibility point of view.

thkala
  • 84,049
  • 23
  • 157
  • 201
1

What you're seeing is pretty much expected. If you poke around the kernel you'll see most references to epoll_create() are down in the arch directory, meaning they are very much architecture dependent. As such it's pretty standard that it can't be invoked directly from userspace.

As for efficiency, take a look man syscall.

As it states in there:
Often the glibc wrapper function is quite thin, doing little work other than copying arguments to the right registers before invoking the system call, and then setting errno appropriately after the system call has returned.

So no, typically there's no big performance hit by this implementation.

Mike
  • 47,263
  • 29
  • 113
  • 177