The problem/use-case that the feature addresses

I am using Redis as a disk-based database (i.e., configured with AOF mode), where the write performance is the most concerning. It is very great that Redis now support I/O threads. But currently the threads can only use the write(2) syscall to issue requests. There may be two limitations: - (1) write(2) is a synchronized I/O interface, which means only one request can stay in-flight. While many new devices can have very deep queue depth, which can serve many requests at a time. - (2) even with asynchronized I/O,
> as devices get extremely fast, interrupt-driven work is no longer as efficient as polling for completions — a common theme that underlies the architecture of performance-oriented I/O systems.

Description of the feature

  • For (1), I suggest making Redis support asynchronized I/O. It is very encouraging that PostgreSQL has already working on it. To achieve so, possible choices are: libaio, io_uring, etc. Since Redis does not manage buffer itself (relying on OS page cache),libaio will fall back to synchronous (in buffered-IO mode and with appendfsync=always).
  • For (2), it would be awesome that Redis can support io_uring as an possible I/O interface. Even if completely changing write to io_uring may brings new problems. Shall we make it configurable (e.g., adding a parameter use-io-uring)?

Thanks & best.