Question

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

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()的主要问题在于其编程接口而不是其性能：

根本没有类型安全 - 如果系统调用期望char *并且程序员提供char，则可能是调用无法按预期工作。编译器无法防止此类错误。
它提供了底层内核接口，没有任何修改，这通常不适合直接在用户应用程序中使用。

另一方面，它不依赖于libc知道并且有相关系统调用的包装器，从兼容性的角度来看这是一个优势。

系统调用的效率

2 个答案: