3

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

  • 是否有任何其他系统调用计划很快使用 vDSO 接口？
  • 是否clock_gettime()真的成为一个足够大的瓶颈来激发 vDSO 的设计？是否有任何特定类型的应用程序对此有所帮助？如果是这样，什么样的应用程序和多少？

为时间查找设计一个新的内核系统调用接口似乎很奇怪。我猜它可以帮助高性能服务器处理诸如时间戳请求响应和日志之类的事情。但我想知道这里是否有人有比猜测更具体的细节。

4

1 回答 1

1

vDSO 背后的原因

vDSO手册页对创建此特殊库的原因进行了说明：

为什么 vDSO 存在？内核提供了一些系统调用，最终用户空间代码经常使用，以至于这些调用可以支配整体性能。这是由于调用的频率以及退出用户空间和进入内核导致的上下文切换开销。

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

这些信息也不是秘密——任何特权模式下的任何应用程序（root 或任何非特权用户）都会得到相同的答案。

注意：强调我的。

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

因此，回顾一下，我们有两个原因/限制来向 vDSO 添加功能：

  1. 功能必须提供非机密信息
  2. 这些功能必须使用太多以至于真的值得转移到 vDSO

可用功能

如果您进一步查看 vDSO 手册页，您会注意到各种实现支持的功能列表（请参阅 * ARCHITECTURE-SPECIFIC NOTES部分）。这为我们提供了另一条信息：实现/可访问某某时的 Linux 版本。第一个可用的实现是在 Linux 2.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 中，也有信号相关的功能。

于 2021-11-01T17:22:36.577 回答