[ALT] core: use a separate syscall thread for aio fallbacks - #299
[ALT] core: use a separate syscall thread for aio fallbacks#299ballard26 wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
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_poolfor linux-aio to serviceaio_fallbacksubmissions separately from other blocking syscalls. - Route
io_threaded_fallbacksmetrics 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.
44971ee to
f505665
Compare
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.
f505665 to
97a443c
Compare
| if (auto* aio_pool = _r._backend->aio_thread_pool()) { | ||
| n += aio_pool->complete(); | ||
| } | ||
| return n; |
There was a problem hiding this comment.
shouldn't this be its own poller added by the aio backend?
travisdowns
left a comment
There was a problem hiding this comment.
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.
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.