Ignore:
Timestamp:
Apr 14, 2022, 4:37:28 PM (6 months ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
master, pthread-emulation, qualifiedEnum
Children:
3e36b1d8
Parents:
365c8dcb
Message:

Pushing what little I have for Chapter 5

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/thierry_delisle_PhD/thesis/text/practice.tex

    r365c8dcb rbfd5512  
    9595
    9696\section{Idle-Sleep}
     97In addition to users manually changing the number of \procs, it is desireable to support ``removing'' \procs when there is not enough \ats for all the \procs to be useful.
     98While manual resizing is expected to be rare, the number of \ats is expected to vary much more which means \procs may need to be ``removed'' for only short periods of time.
     99Furthermore, race conditions that spuriously lead to the impression no \ats are ready are actually common in practice.
     100Therefore \procs should not be actually \emph{removed} but simply put into an idle state where the \gls{kthrd} is blocked until more \ats become ready.
     101This state is referred to as \newterm{Idle-Sleep}.
    97102
    98 \subsection{Tracking Sleepers}
     103Idle sleep effectively encompasses several challenges.
     104First some data structure needs to keep track of all \procs that are in idle sleep.
     105Because of idle sleep can be spurious, this data structure has strict performance requirements in addition to the strict correctness requirements.
     106Next, some tool must be used to block kernel threads \glspl{kthrd}, \eg \texttt{pthread\_cond\_wait}, pthread semaphores.
     107The complexity here is to support \at parking and unparking, timers, \io operations and all other \CFA features with minimal complexity.
     108Finally, idle sleep also includes a heuristic to determine the appropriate number of \procs to be in idle sleep an any given time.
     109This third challenge is however outside the scope of this thesis because developping a general heuristic is involved enough to justify its own work.
     110The \CFA scheduler simply follows the ``Race-to-Idle'\cit{https://doi.org/10.1137/1.9781611973099.100}' approach where a sleeping \proc is woken any time an \at becomes ready and \procs go to idle sleep anytime they run out of work.
     111
     112
     113\section{Tracking Sleepers}
     114Tracking which \procs are in idle sleep requires a data structure holding all the sleeping \procs, but more importantly it requires a concurrent \emph{handshake} so that no \at is stranded on a ready-queue with no active \proc.
     115The classic challenge is when a \at is made ready while a \proc is going to sleep, there is a race where the new \at may not see the sleeping \proc and the sleeping \proc may not see the ready \at.
     116
     117Furthermore, the ``Race-to-Idle'' approach means that there is some
     118
     119\section{Sleeping}
    99120
    100121\subsection{Event FDs}
     
    104125\subsection{\texttt{io\_uring}}
    105126
    106 \subsection{Reducing Latency}
     127\section{Reducing Latency}
Note: See TracChangeset for help on using the changeset viewer.