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

Timestamp:

Aug 25, 2022, 11:52:00 AM (20 months ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

d2f09e4

Parents:

82b9e956

Message:

Added description of NGINX's threading model.
Added section to io.tex describing bounded and unbounded workers.
Added section in eval_macro describing the results for 5.15.
Re-wrote the last paragraph about disk experiments.
It should all be ready to read.

File:

• doc/theses/thierry_delisle_PhD/thesis/text/io.tex (modified) (2 diffs)

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

@@ -158 +158 @@
 The parked \glspl{thrd} are then rescheduled by the event engine once the desired operation has completed.
 
-\subsection{\lstinline{io_uring} in depth}
+\subsection{\lstinline{io_uring} in depth}\label{iouring}
 Before going into details on the design of my event engine, more details on @io_uring@ usage are presented, each important in the design of the engine.
 Figure~\ref{fig:iouring} shows an overview of an @io_uring@ instance.
@@ -216 +216 @@
 This restriction means \io request bursts may have to be subdivided and submitted in chunks at a later time.
 
+An important detail to keep in mind is that just like ``The cloud is just someone else's computer''\cite{xkcd:cloud}, asynchronous operations are just operation using someone else's threads.
+Indeed, asynchronous operation can require computation time to complete, which means that if this time is not taken from the thread that triggered the asynchronous operation, it must be taken from some other threads.
+In this case, the @io_uring@ operations that cannot be handled directly in the system call must be delegated to some other \gls{kthrd}.
+To this end, @io_uring@ maintains multiple \glspl{kthrd} inside the kernel that are not exposed to the user.
+There are three kind of operations that can need the \glspl{kthrd}:
+
+\paragraph{Operations using} @IOSQE_ASYNC@.
+This is a straightforward case, users can explicitly set the @IOSQE_ASYNC@ flag on an SQE to specify that it \emph{must} be delegated to a different \gls{kthrd}.
+
+\paragraph{Bounded operations.}
+This is also a fairly simple case. As mentioned earlier in this chapter, [@O_NONBLOCK@] has no effect for regular files and block devices.
+@io_uring@ must also take this reality into account by delegating operations on regular files and block devices.
+In fact @io_uring@ maintains a pool of \glspl{kthrd} dedicated to these operations, which are referred to as \newterm{bounded workers}.
+
+\paragraph{Unbounded operations that must be retried.}
+While operations like reads on sockets can return @EAGAIN@ instead of blocking the \gls{kthrd}, in the case these operations return @EAGAIN@ they must be retried by @io_uring@ once the data is available on the socket.
+Since this retry cannot necessarily be done in the system call, @io_uring@ must delegate these calls to a \gls{kthrd}.
+@io_uring@ maintains a separate pool for these operations.
+The \glspl{kthrd} in this pool are referred to as \newterm{unbounded workers}.
+Unbounded workers are also responsible of handling operations using @IOSQE_ASYNC@.
+
+@io_uring@ implicitly spawns and joins both the bounded and unbounded workers based on its evaluation of the needs of the workload.
+This effectively encapsulates the work that is needed when using @epoll@.
+Indeed, @io_uring@ does not change Linux's underlying handling of \io opeartions, it simply offers an asynchronous \glsxtrshort{api} on top of the existing system.
+
+
 \subsection{Multiplexing \io: Submission}