Changes in doc/theses/thierry_delisle_PhD/thesis/text/io.tex [f2bc9fa:6db62fa]

File:

• doc/theses/thierry_delisle_PhD/thesis/text/io.tex (modified) (1 diff)

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

@@ -330 +330 @@
 \paragraph{Pending Allocations} can be more complicated to handle.
 If the arbiter has available instances, the arbiter can attempt to directly hand over the instance and satisfy the request.
-Otherwise
+Otherwise it must hold onto the list of threads until SQEs are made available again.
+This handling becomes that much more complex if pending allocation require more than one SQE, since the arbiter must make a decision between statisfying requests in FIFO ordering or satisfy requests for fewer SQEs first.
+
+While this arbiter has the potential to solve many of the problems mentionned in above, it also introduces a significant amount of complexity.
+Tracking which processors are borrowing which instances and which instances have SQEs available ends-up adding a significant synchronization prelude to any I/O operation.
+Any submission must start with a handshake that pins the currently borrowed instance, if available.
+An attempt to allocate is then made, but the arbiter can concurrently be attempting to allocate from the same instance from a different \gls{hthrd}.
+Once the allocation is completed, the submission must still check that the instance is still burrowed before attempt to flush.
+These extra synchronization steps end-up having a similar cost to the multiple shared instances approach.
+Furthermore, if the number of instances does not match the number of processors actively submitting I/O, the system can fall into a state where instances are constantly being revoked and end-up cycling the processors, which leads to significant cache deterioration.
+Because of these reasons, this approach, which sounds promising on paper, does not improve on the private instance approach in practice.
+
+\subsubsection{Private Instances V2}
+