vDSO:为什么linux只将它们用于与时间相关的函数？

Question

刚刚在Linux内核中搜索vdso钩子(例如，在kernel.org上找到了kernel.org)，它目前似乎主要用于与时间相关的系统调用。这使人想起两个问题：

• 是否还有其他系统调用计划很快使用vDSO接口？
• clock_gettime()是否真的成为一个足够大的瓶颈来激励vDSO的设计？有什么特别的申请是有帮助的吗？如果是的话，什么样的申请和多少费用？

为时间查找设计一个新的内核syscall接口似乎有点奇怪。我猜它有助于高性能服务器的事情，如时间戳请求-响应和日志。但我想知道这里是否有比猜测更具体的细节。

Answer 1

vDSO背后的原因

关于创建这个特殊库的原因，vDSO手册页有如下内容：

为什么vDSO会存在？内核提供了一些系统调用，即用户空间代码最终会频繁使用，以至于这样的调用可以控制总体性能。这既是由于调用的频率，也是由于退出用户空间和进入内核而产生的上下文切换开销。

进一步阅读将告诉您用于在内核和用户空间之间共享数据的各种策略。特别是：

这些信息也是，而不是秘密的-any应用程序，在任何特权模式下(根用户或任何非特权用户)都会得到相同的答案。

注:强调我的。

这告诉我们，通过vDSO接口提供的数据必须是公开的，系统上运行的任何进程都可以访问这些数据。这显然是非常重要的。

因此，综上所述，我们向vDSO添加函数有两个原因/约束：

1. 这些功能必须提供非秘密的信息。
2. 这些函数必须大量使用，因此真正值得迁移到vDSO中。

可用职能

如果您进一步查看vDSO手册页面，您将注意到各种实现所支持的函数列表(请参阅特定于体系结构的说明部分)。这给了我们另一条信息: Linux版本在实现/可访问的时候。第一个可用的实现是Linux2.5 (2001年底，注意，这也是一个开发版本，所以2003年的第一个可用用户版本是2.6.1 )。

我们在vDSO中找到以下函数：

sigreturn
rt_sigreturn
sigtramp
sigtramp32
sigtramp_rt32
sigtramp_rt64

syscall_via_break
syscall_via_epc
vsyscall
get_syscall_map
lws_entry
linux_gateway_entry

gettimeofday
clock_gettime
clock_gettime64
clock_getres
time

getcpu
get_tbfreq
sync_dicache
sync_dicache_p5
flush_icache

getpid
getppid
set_tid_address
set_thread_pointer
datapage_offset

因此，总的来说，我们看到呼吁：

• 信号
• 系统/内核
• 时间
• CPU/缓存
• 进程

对于x86处理器，它主要是受限于时间和CPU。在i386中，也有与信号相关的功能。