Changeset fc6c410 for doc/theses/thierry_delisle_PhD/thesis/text/io.tex
- Timestamp:
- Aug 25, 2022, 11:52:00 AM (2 years ago)
- Branches:
- ADT, ast-experimental, master, pthread-emulation
- Children:
- d2f09e4
- Parents:
- 82b9e956
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/thierry_delisle_PhD/thesis/text/io.tex
r82b9e956 rfc6c410 158 158 The parked \glspl{thrd} are then rescheduled by the event engine once the desired operation has completed. 159 159 160 \subsection{\lstinline{io_uring} in depth} 160 \subsection{\lstinline{io_uring} in depth}\label{iouring} 161 161 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. 162 162 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. 217 217 218 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. 219 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. 220 In this case, the @io_uring@ operations that cannot be handled directly in the system call must be delegated to some other \gls{kthrd}. 221 To this end, @io_uring@ maintains multiple \glspl{kthrd} inside the kernel that are not exposed to the user. 222 There are three kind of operations that can need the \glspl{kthrd}: 223 224 \paragraph{Operations using} @IOSQE_ASYNC@. 225 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}. 226 227 \paragraph{Bounded operations.} 228 This is also a fairly simple case. As mentioned earlier in this chapter, [@O_NONBLOCK@] has no effect for regular files and block devices. 229 @io_uring@ must also take this reality into account by delegating operations on regular files and block devices. 230 In fact @io_uring@ maintains a pool of \glspl{kthrd} dedicated to these operations, which are referred to as \newterm{bounded workers}. 231 232 \paragraph{Unbounded operations that must be retried.} 233 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. 234 Since this retry cannot necessarily be done in the system call, @io_uring@ must delegate these calls to a \gls{kthrd}. 235 @io_uring@ maintains a separate pool for these operations. 236 The \glspl{kthrd} in this pool are referred to as \newterm{unbounded workers}. 237 Unbounded workers are also responsible of handling operations using @IOSQE_ASYNC@. 238 239 @io_uring@ implicitly spawns and joins both the bounded and unbounded workers based on its evaluation of the needs of the workload. 240 This effectively encapsulates the work that is needed when using @epoll@. 241 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. 242 243 218 244 \subsection{Multiplexing \io: Submission} 219 245
Note: See TracChangeset
for help on using the changeset viewer.