【问题标题】:write to eventfd using Linux AIO使用 Linux AIO 写入 eventfd
【发布时间】:2017-05-11 18:15:57
【问题描述】:

我的应用程序充当系统上运行的其他应用程序的高性能服务器。在开发过程中,我测量到大约 30% 的内核仅用于调用 eventfd_write(),因此尝试使用 libaio 使用单个系统调用编写多个 eventfd。然后我发现eventfd不支持AIO。

不为 eventfd 实现 AIO 是否有任何明显的障碍,或者暂时没有人需要它?

您知道任何尝试为 eventfd 实现 AIO 的现有工作吗?

【问题讨论】:

  • 对 eventfd 的读/写只涉及在 RAM 中读取或写入 8 字节整数。我想通过 AIO 做同样的事情会增加不成比例的开销。因此,为此使用 AIO 没有任何好处。
  • 是的,我知道,但是当每秒向大约 30 个或更多不同的 eventfd 发出 1M eventfd_writes 时,它会在每次系统调用时开始计时,这就是为什么要求这个问题通过发出几次写入来减少系统调用计数一次。
  • "1M eventfd_writes per second" ← 你的问题。你真的有 100 万个不同的事件吗?还是他们真的经常阅读?
  • 是的,这是客户要求的。事实上,我能够处理超过 1M/秒的请求,但其中大约 1M 必须发出信号。我想我会尝试为 AIO 扩展 eventfd,看看这是否会带来任何可衡量的性能提升。
  • 我认为您不会从 io_submit 中获得所需的性能。在我用它做的事情中,它的执行时间总是随着 iovec 中条目的数量而增加。它不像 O(N) 那样糟糕,但你肯定不会以一个请求 io_submit 的成本提交 >1 个请求。我认为想出一种合并信令的方法会更好地为您服务,也许想出一个带外协议来处理一个 eventfd 写入的多个“事件”。

标签: c linux performance linux-kernel aio


【解决方案1】:

尽管写入 eventfd 只是写入内存,但写入本身就是一个系统调用。所以你的 CPU 必须切换上下文,跳转到内核,快速写入,然后切换回你的用户空间应用程序。

上下文切换的成本很高,远不止一次 64 位写入。

我们有什么选择?

  1. 不要使用 eventfd,在共享内存中使用原子标志。您将消除系统调用,您的性能将显着提高。

  2. 不要在每个事件上写入 eventfd:

    • 考虑将您的事件分批分组,每批只写一次。
    • 当您有一个非空的事件队列时,考虑切换到轮询模式,然后在队列再次为空时切换回来。
  3. 如果在您的上下文中有意义,请将 eventfd 写入移动到单独的线程。

我相信你更了解你的应用程序,所以你会想出更多的优化......如果不是 - 只需在 StackOverflow 上询问;)

【讨论】:

  • 如果使用 select/poll/epoll 监控 eventfd,第一个建议实际上并不可行:我不知道如何使普通的原子标志 I/O 可复用。
  • @DanielKamilKozar 我建议使用原子标志来避免系统调用。因为我们需要更多的性能。当然,这意味着我们进行轮询,而不仅仅是等待事件。不太了解“I/O-multiplexable”部分。能详细点吗?
猜你喜欢
  • 1970-01-01
  • 2017-06-21
  • 2013-06-04
  • 2018-01-25
  • 1970-01-01
  • 2012-01-20
  • 2011-10-18
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多