Skip to content

[ALT] core: use a separate syscall thread for aio fallbacks - #299

Open
ballard26 wants to merge 1 commit into
redpanda-data:v26.2.xfrom
ballard26:aio-syscall-thread-alt
Open

[ALT] core: use a separate syscall thread for aio fallbacks#299
ballard26 wants to merge 1 commit into
redpanda-data:v26.2.xfrom
ballard26:aio-syscall-thread-alt

Conversation

@ballard26

Copy link
Copy Markdown

The reactor offloads blocking syscalls onto a single syscall thread. On the linux-aio backend this thread also serves aio read/write submissions that fall back to a blocking io_submit(), so a slow or stalled file or process syscall (e.g. open, stat, fsync, waitpid) can delay aio retries queued behind it, and vice versa.

Split the work when the linux-aio backend is in use. A dedicated syscall thread and queue now serve aio submission fallbacks, while the existing thread keeps handling every other blocking syscall. Submissions are routed by their thread_pool_submit_reason, so aio_fallback work no longer shares a queue with file and process operations. Other backends, which have no aio fallback path, keep using a single worker as before.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR reduces latency interference between unrelated blocking syscalls and linux-aio io_submit() fallback submissions by splitting the reactor’s syscall offload work into two thread pools when the linux-aio backend is selected.

Changes:

  • Create a dedicated _aio_thread_pool for linux-aio to service aio_fallback submissions separately from other blocking syscalls.
  • Route io_threaded_fallbacks metrics to the correct thread pool depending on the submit reason.
  • Extend the syscall poller to complete/interrupt-manage both thread pools when present.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
src/core/reactor.cc Conditionally creates and services a second thread pool for AIO fallbacks; updates metrics routing and polling/interrupt handling.
src/core/reactor_backend.cc Routes AIO retry submissions (io_submit() fallbacks) to the AIO-dedicated syscall thread for linux-aio.
include/seastar/core/reactor.hh Adds the _aio_thread_pool member with clarifying comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/core/reactor_backend.cc Outdated

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

Comment thread src/core/reactor_backend.cc
The reactor offloads blocking syscalls onto a single syscall thread. Disk
aio submissions can fall back to a blocking io_submit() (in
aio_storage_context, used by both the linux-aio and epoll backends), so a
slow or stalled file or process syscall (e.g. open, stat, fsync, waitpid)
can delay the aio retries queued behind it, and vice versa.

Give aio_storage_context its own syscall thread for that io_submit()
fallback, so aio submissions no longer share a queue with file and process
operations. The pool lives wherever an aio_storage_context does (the
linux-aio and epoll backends) and is exposed to the reactor's syscall
poller via reactor_backend::aio_thread_pool(); backends without disk aio
(io_uring) have none.
@ballard26
ballard26 force-pushed the aio-syscall-thread-alt branch from f505665 to 97a443c Compare July 16, 2026 02:19
Comment thread src/core/reactor.cc
if (auto* aio_pool = _r._backend->aio_thread_pool()) {
n += aio_pool->complete();
}
return n;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be its own poller added by the aio backend?

@travisdowns travisdowns left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like maybe we should still bit it "more" into the aio backend? E.g., now we expand the existing poller in the reactor to know about the aio poller, which is backend specific, but maybe it should be a new poller which is registered by the aio backend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants