Context Navigation

-                      r1c334d1
+                      rfc96890
 Its interface lets programmers enqueue operations to be performed asynchronously by the kernel.
 Completions of these operations can be communicated in various ways: either by spawning a new \gls{kthrd}, sending a Linux signal, or polling for completion of one or more operations.
 For this work, spawning a new \gls{kthrd} is counter-productive but a related solution is discussed in Section~\ref{io:morethreads}.
+For this work, spawning a new \gls{kthrd} is counterproductive but a related solution is discussed in Section~\ref{io:morethreads}.
 Using interrupt handlers can also lead to fairly complicated interactions between subsystems and has a non-trivial cost.
 Leaving polling for completion, which is similar to the previous system calls.
 …
 \subsection{Extra Kernel Threads}\label{io:morethreads}
 Finally, if the operating system does not offer a satisfactory form of asynchronous \io operations, an ad-hoc solution is to create a pool of \glspl{kthrd} and delegate operations to it to avoid blocking \glspl{proc}, which is a compromise for multiplexing.
+Finally, if the operating system does not offer a satisfactory form of asynchronous \io operations, an ad hoc solution is to create a pool of \glspl{kthrd} and delegate operations to it to avoid blocking \glspl{proc}, which is a compromise for multiplexing.
 In the worst case, where all \ats are consistently blocking on \io, it devolves into 1-to-1 threading.
 However, regardless of the frequency of \io operations, it achieves the fundamental goal of not blocking \glspl{proc} when \ats are ready to run.
 …
 Allocation failures need to be pushed to a routing algorithm: \ats attempting \io operations must not be directed to @io_uring@ instances without sufficient SQEs available.
 Furthermore, the routing algorithm should block operations up-front, if none of the instances have available SQEs.
+Furthermore, the routing algorithm should block operations upfront if none of the instances have available SQEs.
 Once an SQE is allocated, \ats insert the \io request information and keep track of the SQE index and the instance it belongs to.
 Once an SQE is filled in, it is added to the submission ring buffer, an operation that is not thread-safe, and then the kernel must be notified using the @io_uring_enter@ system call.
+Once an SQE is filled in, it is added to the submission ring buffer, an operation that is not thread safe, and then the kernel must be notified using the @io_uring_enter@ system call.
 The submission ring buffer is the same size as the pre-allocated SQE buffer, therefore pushing to the ring buffer cannot fail because it would mean an SQE multiple times in the ring buffer, which is undefined behaviour.
 However, as mentioned, the system call itself can fail with the expectation that it can be retried once some submitted operations are complete.
 …
 Once the system call is done, the submitter must also free SQEs so that the allocator can reuse them.
 Finally, the completion side is much simpler since the @io_uring@ system-call enforces a natural synchronization point.
+Finally, the completion side is much simpler since the @io_uring@ system call enforces a natural synchronization point.
 Polling simply needs to regularly do the system call, go through the produced CQEs and communicate the result back to the originating \ats.
 Since CQEs only own a signed 32-bit result, in addition to the copy of the @user_data@ field, all that is needed to communicate the result is a simple future~\cite{wiki:future}.
 …
 \paragraph{Pending Allocations} are handled by the arbiter when it has available instances and can directly hand over the instance and satisfy the request.
 Otherwise, it must hold onto the list of threads until SQEs are made available again.
+Otherwise, it must hold on to the list of threads until SQEs are made available again.
 This handling is more complex when an allocation requires multiple SQEs, since the arbiter must make a decision between satisfying requests in FIFO ordering or for fewer SQEs.
 …
 The last important part of the \io subsystem is its interface.
 Multiple approaches can be offered to programmers, each with advantages and disadvantages.
 The new \io subsystem can replace the C runtime API or extend it, and in the later case, the interface can go from very similar to vastly different.
+The new \io subsystem can replace the C runtime API or extend it, and in the latter case, the interface can go from very similar to vastly different.
 The following sections discuss some useful options using @read@ as an example.
 The standard Linux interface for C is :
+The standard Linux interface for C is:
 \begin{cfa}
 ssize_t read(int fd, void *buf, size_t count);
 …
 The goal is to convince the compiler and linker to replace any calls to @read@ to direct them to the \CFA implementation instead of glibc's.
 This rerouting has the advantage of working transparently and supporting existing binaries without needing recompilation.
 It also offers a, presumably, well-known and familiar API that C programmers can simply continue to work with.
+It also offers a, presumably, well known and familiar API that C programmers can simply continue to work with.
 However, this approach also entails a plethora of subtle technical challenges, which generally boils down to making a perfect replacement.
 If the \CFA interface replaces only \emph{some} of the calls to glibc, then this can easily lead to esoteric concurrency bugs.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset fc96890 for doc/theses/thierry_delisle_PhD/thesis/text/io.tex

Legend:

doc/theses/thierry_delisle_PhD/thesis/text/io.tex

Download in other formats: