考虑一个受CPU约束但又具有高性能I / O要求的应用程序。
我正在将Linux文件I / O与Windows进行比较,我完全看不出epoll将如何帮助Linux程序。内核会告诉我文件描述符“可以读取”,但是我仍然必须调用阻塞read()来获取数据,并且如果我想读取兆字节,很显然它将阻塞。
在Windows上,我可以创建带有OVERLAPPED设置的文件句柄,然后使用非阻塞I / O,并在I / O完成时得到通知,并使用该完成功能中的数据。我不需要花费应用程序级别的时钟时间来等待数据,这意味着我可以将线程数精确地调整为内核数,并获得100%的高效CPU利用率。
如果我必须在Linux上模拟异步I / O,则必须分配一定数量的线程来执行此操作,这些线程将花费一点时间来做CPU事情,并且会花费大量时间来阻塞I / O,加上与这些线程之间的消息传递会产生开销。因此,我将过度订购或未充分利用CPU内核。
我将mmap()+ madvise()(WILLNEED)视作“可怜的人的异步I / O”,但它仍然无法一路走到尽头,因为完成后我无法收到通知- 我有为“猜测”,如果我猜为“错误”,我将最终阻止内存访问,等待数据来自磁盘。
Linux似乎在io_submit中启动了异步I / O,并且它似乎也有一个用户空间POSIX aio实现,但是这种方式已经存在了一段时间,而且我知道没有人会为这些系统提供关键服务,高性能的应用程序。
Windows模型大致如下所示:
第1/2步通常是一件简单的事情。步骤3/4通常是使用工作线程池完成的,而不是(不一定)与发出I / O的线程相同。该模型与boost :: asio提供的模型有些相似,除了boost :: asio实际上并没有为您提供基于异步块的(磁盘)I / O。
与Linux中的epoll的不同之处在于,在第4步中,尚未发生任何I / O -将第1步提升到第4步之后,如果您确切地知道自己需要什么,则将其“倒退”。
对大量嵌入式,桌面和服务器操作系统进行了编程之后,我可以说这种异步I / O模型对于某些类型的程序来说是很自然的。它也是高吞吐量和低开销的。我认为这是Linux I / O模型在API级别上仍然存在的真正缺陷之一。
Peter Teoh间接指出的真实答案是基于io_setup()和io_submit()的。具体来说,由Peter指示的“ aio_”功能是基于线程的glibc用户级仿真的一部分,这不是有效的实现。真正的答案是:
io_submit(2) io_setup(2) io_cancel(2) io_destroy(2) io_getevents(2)
请注意,日期为2012-08的手册页指出,该实现尚未成熟到可以代替glibc用户空间仿真的程度:
http://man7.org/linux/man-pages/man7/aio.7.html
该实现尚未成熟到可以使用内核系统调用完全重新实现POSIX AIO实现的地步。
因此,根据我可以找到的最新内核文档,Linux尚没有成熟的基于内核的异步I / O模型。而且,如果我假设记录的模型实际上已经成熟,那么从recv()vs read()的角度来看,它仍然不支持部分I / O。