FreeBSD along the journey • PostgreSQL disk AIO project started by Andres Freund, later joined by Thomas Munro, Melanie Plageman, David Rowley, being proposed for PostgreSQL 16 io_method={worker,io_uring,posix_aio,windows_iocp} io_data_direct={on,off} io_wal_direct={on,off} All supported OSes Linux POSIX, especially FreeBSD Windows
levels of bu ff er • Data is transferred between caches 8KB at a time with a lot of synchronous pread/pwrite • Relying on kernel heuristics for readhead and writeback • We give limited hints about future reads and fsyncs on some OSes for IO concurrency (but not FreeBSD 😔) Bu ff er cache/ARC Bu ff er pool WAL bu ff ers PostgreSQL’s traditional disk I/O
er cache, no double bu ff ering, no kernel copying • Submit and complete batches of IOs with minimal system calls via modern* asynchronous interfaces • Combine IOs (adjacent data, scatter/ gather) • Make our own specialised IO streaming predictors (not just “detect sequential”, but data-dependent) • Model and control IO with certain goals (latency, resource usage, …) Bu ff er pool WAL bu ff ers AIO/DIO
from t; count --------- 1000000 (1 row) Disable query executor parallelism, to make this example simple We’ll scan a table that isn’t in PostgreSQL’s buffer pool
API <io_method> Logic for controlling IO depth is common infrastructure, working in batches, to allow for IO combining; Research topic: control theory algorithms Logic for how to initiate one more IO is provided by from consumer/ producer Index scans, recovery/ replication system, checkpointer, …
be faulting in pages concurrently Replicas would synchronously fault in one page at a time; fi xed with AIO-based prefetching postgres=# select wal_distance, io_depth from pg_stat_recovery_prefetch; wal_distance | io_depth ——————————————+—————————- 3272 | 7
covered by POSIX so no formal meaning; general idea “don’t bu ff er my data” • Systems di ff er in details (block alignment requirements, e ff ects on descriptors with di ff erent fl ags, support on di ff erent fi le systems) • There were also some other ideas: Sun’s directio() and mount options, Apple’s F_NOCACHE • AFAIK, mostly of interest to database hackers and big data graphics/science • Speculation: one of the motivations for 90s databases to use raw disk partitions was perhaps to skip the kernel’s bu ff er cache, IO scheduler and concurrency/locking problems; O_DIRECT and highly concurrent fi le systems address those issues
replacement logic and bu ff er pool size had better be good, because the kernel’s bu ff ering won’t be cushioning our misses • We’ll need to supply readhead, writeback, clustering and concurrency logic, even for the simplest straight-line cases • -> AIO and DIO go together like peanut butter and jelly • Slower unbu ff ered reads and writes may reveal locking problems in fi lesystem implementation (gulp)
RSX-11M • Asynchronous interfaces everywhere (“overlapped”) • Event-based polling and callbacks • 1994: Windows NT 3.5 • Adds IOCP for queue-like event processing • 1993: POSIX AIO, RT signals • IOs can now be started asynchronously • RT signals can carry a payload for example an IO number/pointer, and be consumed synchronously from a per-process queue or call handlers • Alternative polling scheme Nearly three decades of AIO
for batched submission of LIO_READ, LIO_WRITE • FreeBSD 13 added non-standard extensions aio_readv(), aio_writev(), LIO_READV, LIO_WRITEV for vector IO (scatter/gather) • Along the same lines, preadv()/pwritev() are also curiously absent from POSIX, but are obvious combinations of pread()/pwrite() and readv()/writev()
if it’s fi nished, failed or EINPROGRESS • aio_return() to get the result • aio_suspend() to wait for a list of IOs to complete, then see above to fi nd out which ones (reads and writes only, no fsyncs, though almost all implementations allow sync to be waited for too)
give you read-from-a-queue style interface, at a cost of three syscalls per IO (sigwaitinfo(), aio_error(), aio_return()), but macOS didn’t implement it! You could do sigwait() and then aio_error() for all outstanding IOs, for O(n^2) syscalls… • Using signal handlers would be unpleasant, and glibc has some questionable async signal safety • SIGEV_THREAD • Call a function pointer in some unspeci fi ed thread. As a matter of policy we probably don’t want threads for this, but in any case macOS didn’t implement it… • SIGEV_NONE • You’ll have to use aio_suspend() to wait, and then O(n^2). Only HP-UX doesn’t allow aio_fsync() to be waited for with aio_suspend() (which is allowed by POSIX, why?!)
much nicer queue-like system • SIGEV_KEVENT (FreeBSD): drain N from a kqueue • You still have to call aio_return() on each IO, and possibly aio_error() too*, so you cannot get below 1.x syscalls per IO! • macOS and NetBSD have both kqueue and AIO, but they are not connected; Dragon fl y removed AIO. • aio_waitcomplete() (FreeBSD): drain one like a queue; no aio_error() or aio_return() • AIX’s aio_nwait() (but doesn’t work for aio_fsync()!), Solaris’s aio_waitn(), HP-UX’s aio_reap() could all read batches of completions, some without even entering the kernel • AIX and Solaris also added Windows IOCP-style APIs (not explored by me; SIGEV_PORT?)
close a descriptor while an IO is pending? • The IO should run to completion • ECANCELED • The system should go bananas and run the IO against some later user of the same fi le descriptor number • What should happen if you perform multiple IOs on the same descriptor? • They should run in parallel to the extend possible • Serialise them, surely the calling program jests • POSIX says that aio_suspend() can’t wait for aio_fsync() (only HP-UX doesn’t support fsync here) • You can’t complete IOs started by another process. OK, maybe not so surprising. PostgreSQL really needs to go multi-threaded…
instead of whole writes • UFS has a fast bu ff erless path for O_DIRECT reads, but not vector reads (which should ideally produce a single multi-segment read at the device level), and no equivalent for writes • UFS fsync()/fdatasync() doesn’t fl ush device caches or use FUA • UFS uses VFS-level writes locks for write() and fsync(), preventing concurrency • VFS doesn’t allow for true asynchronous IO, instead kernel threads call the synchronous entry points and sleep
be able to use SEGEV_KEVENT to consume completion events from a kqueue without having to call aio_return(). Then we could get below 1 system call per IO, like on other OSes. • I have some prototype code for this: see D33271, D33144. It’s tricky, there are many places in the kernel that assume that IO is synchronous… • I have heard suggestions that kevent() should also be able to start IOs too
macdice
fast_doctor
koukimiura
daisuketakeda
.jpg){kind=avatar}
tak_dcxi
tchov
1mash0
saitoryc
ryunakayama
syossan27
dwchiang
algoartis
holman
jeffersonlam
vanstee
bcantrill
jonrohan
lara
rasmusluckow
eileencodes
caitiem20
aki_iinuma
rocio
eitanlees
![epoll_wait(12, [{EPOLLIN, {u32=2507243840, u64=94075175928128}}], 1, -1) = 1 recvfrom(16, "Q\0\0\0\34select](https://files.speakerdeck.com/presentations/4494929892774b82a1a44d9632d3e5c2/slide_10.jpg){kind=link}
