syscall的效率

Question

我正在阅读libevent的源代码，当它需要调用epoll_create时，它使用了系统调用insteaded。

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

后一种情况会提高性能吗？

Answer 1

你所看到的是非常期待的。如果你在内核中搜索，你会发现epoll_create()的大多数引用都在arch目录下，这意味着它们非常依赖于架构。因此，它是非常标准的，它不能从用户空间直接调用。

至于效率，看看man syscall。

因为它在那里指出：
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.

所以，不，通常没有大的表现本实施打击。

Answer 2

syscall()是执行系统调用的通用函数。即使当前C库比正在运行的内核老，它也允许执行系统调用，因此不支持所有可用的系统调用。

在Linux上，epoll_create()是系统调用，而不是库函数。考虑到从用户空间切换到内核空间和返回的成本以及调用本身的成本，与使用调用程序通过更具体的包装器使用变量syscall()相关的任何开销可能可以忽略不计（如果它完全存在）。

与syscall()的主要问题有它的编程接口，比它的性能做多：

1. 毫无类型安全可言 - 如果系统调用需要一个char *和程序员提供了一个char ，这个电话很可能无法按预期工作。编译器无法防止此类错误。

2. 它提供了没有修改的底层内核接口，这通常不太适合在用户应用程序中直接使用。

在另一方面，它不依赖于libc意识到并具有用于所讨论的系统调用，这是从一个点的相容性的优点的包装。