1 edited


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

    rf2bc9fa r6db62fa  
    330330\paragraph{Pending Allocations} can be more complicated to handle.
    331331If the arbiter has available instances, the arbiter can attempt to directly hand over the instance and satisfy the request.
    332 Otherwise
     332Otherwise it must hold onto the list of threads until SQEs are made available again.
     333This 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.
     335While this arbiter has the potential to solve many of the problems mentionned in above, it also introduces a significant amount of complexity.
     336Tracking which processors are borrowing which instances and which instances have SQEs available ends-up adding a significant synchronization prelude to any I/O operation.
     337Any submission must start with a handshake that pins the currently borrowed instance, if available.
     338An attempt to allocate is then made, but the arbiter can concurrently be attempting to allocate from the same instance from a different \gls{hthrd}.
     339Once the allocation is completed, the submission must still check that the instance is still burrowed before attempt to flush.
     340These extra synchronization steps end-up having a similar cost to the multiple shared instances approach.
     341Furthermore, 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.
     342Because of these reasons, this approach, which sounds promising on paper, does not improve on the private instance approach in practice.
     344\subsubsection{Private Instances V2}
Note: See TracChangeset for help on using the changeset viewer.