【发布时间】：2014-01-07 14:09:02
【问题描述】：
我正在编写一个使用 Linux 异步 I/O 系统调用的库，并且想知道为什么 io_submit 函数在 ext4 文件系统上的扩展性较差。如果可能，我该怎么做才能让io_submit 不阻止大 IO 请求大小？我已经做了以下事情（如here 所述）：
- 使用
O_DIRECT。 - 将 IO 缓冲区对齐到 512 字节边界。
- 将缓冲区大小设置为页面大小的倍数。
为了观察内核在io_submit 中花费了多长时间，我运行了一个测试，其中我使用dd 和/dev/urandom 创建了一个1 Gb 的测试文件，并反复删除了系统缓存（sync; echo 1 > /proc/sys/vm/drop_caches）并读取文件的越来越大的部分。在每次迭代中，我打印了io_submit 花费的时间以及等待读取请求完成所花费的时间。我在运行 Arch Linux 的 x86-64 系统上运行了以下实验，内核版本为 3.11。该机器具有 SSD 和 Core i7 CPU。第一张图绘制了阅读的页数与等待io_submit 完成所花费的时间。第二个图表显示等待读取请求完成所花费的时间。时间以秒为单位。
为了比较，我创建了一个类似的测试，它通过pread 使用同步IO。结果如下：
似乎异步 IO 按预期工作，请求大小约为 20,000 个页面。之后，io_submit 块。这些观察导致以下问题：
- 为什么
io_submit的执行时间不是常数？ - 是什么导致了这种不良的缩放行为？
- 是否需要将 ext4 文件系统上的所有读取请求拆分为多个请求，每个请求的大小小于 20,000 页？
- 20,000 这个“神奇”值从何而来？如果我在另一个 Linux 系统上运行我的程序，我如何才能确定要使用的最大 IO 请求大小而不会遇到糟糕的扩展行为？
用于测试异步 IO 的代码如下。如果您认为其他来源列表相关，我可以添加它们，但我尝试仅发布我认为可能相关的详细信息。
#include <cstddef>
#include <cstdint>
#include <cstring>
#include <chrono>
#include <iostream>
#include <memory>
#include <fcntl.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
// For `__NR_*` system call definitions.
#include <sys/syscall.h>
#include <linux/aio_abi.h>
static int
io_setup(unsigned n, aio_context_t* c)
{
return syscall(__NR_io_setup, n, c);
}
static int
io_destroy(aio_context_t c)
{
return syscall(__NR_io_destroy, c);
}
static int
io_submit(aio_context_t c, long n, iocb** b)
{
return syscall(__NR_io_submit, c, n, b);
}
static int
io_getevents(aio_context_t c, long min, long max, io_event* e, timespec* t)
{
return syscall(__NR_io_getevents, c, min, max, e, t);
}
int main(int argc, char** argv)
{
using namespace std::chrono;
const auto n = 4096 * size_t(std::atoi(argv[1]));
// Initialize the file descriptor. If O_DIRECT is not used, the kernel
// will block on `io_submit` until the job finishes, because non-direct
// IO via the `aio` interface is not implemented (to my knowledge).
auto fd = ::open("dat/test.dat", O_RDONLY | O_DIRECT | O_NOATIME);
if (fd < 0) {
::perror("Error opening file");
return EXIT_FAILURE;
}
char* p;
auto r = ::posix_memalign((void**)&p, 512, n);
if (r != 0) {
std::cerr << "posix_memalign failed." << std::endl;
return EXIT_FAILURE;
}
auto del = [](char* p) { std::free(p); };
std::unique_ptr<char[], decltype(del)> buf{p, del};
// Initialize the IO context.
aio_context_t c{0};
r = io_setup(4, &c);
if (r < 0) {
::perror("Error invoking io_setup");
return EXIT_FAILURE;
}
// Setup I/O control block.
iocb b;
std::memset(&b, 0, sizeof(b));
b.aio_fildes = fd;
b.aio_lio_opcode = IOCB_CMD_PREAD;
// Command-specific options for `pread`.
b.aio_buf = (uint64_t)buf.get();
b.aio_offset = 0;
b.aio_nbytes = n;
iocb* bs[1] = {&b};
auto t1 = high_resolution_clock::now();
auto r = io_submit(c, 1, bs);
if (r != 1) {
if (r == -1) {
::perror("Error invoking io_submit");
}
else {
std::cerr << "Could not submit request." << std::endl;
}
return EXIT_FAILURE;
}
auto t2 = high_resolution_clock::now();
auto count = duration_cast<duration<double>>(t2 - t1).count();
// Print the wait time.
std::cout << count << " ";
io_event e[1];
t1 = high_resolution_clock::now();
r = io_getevents(c, 1, 1, e, NULL);
t2 = high_resolution_clock::now();
count = duration_cast<duration<double>>(t2 - t1).count();
// Print the read time.
std::cout << count << std::endl;
r = io_destroy(c);
if (r < 0) {
::perror("Error invoking io_destroy");
return EXIT_FAILURE;
}
}
【问题讨论】：
-
您是否对旧内核版本进行了相同的测试？例如3.4？我这么说只是为了确保这不是由于内核中最近出现的尚未发现的错误造成的。
-
@Shahbaz 不，还没有——感谢您的建议。我会这样做并在这里再次发布。
-
我不明白你的图表。它看起来像 20K 页面后的 AIO以恒定时间运行，而不是块。
-
@n.m.是的，看起来大部分的IO都是在
io_submit函数中完成的，这就是阻塞。 “等待读取请求完成所花费的时间”是指等待io_getevents返回所花费的时间。但由于io_submit是线性缩放 w.r.t。请求大小，io_getevents将在恒定时间内返回是有道理的。我在描述某事时犯了错误吗？ -
啊，我明白了。您的第二张图仅适用于 io_getevents。现在很清楚了。