Changes in / [24a3d2b:970fa54]

File:

• doc/theses/thierry_delisle_PhD/thesis/text/practice.tex (modified) (3 diffs)

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

@@ -97 +97 @@
 \end{figure}
 
-\section{Idle-Sleep}
+\section{Idle-Sleep}\label{idlesleep}
 While manual resizing of \procs is expected to be rare, the number of \ats can vary significantly over an application's lifetime, which means there are times when there are too few or too many \procs.
 For this work, it is the programer's responsibility to manually create \procs, so if there are too few \procs, the application must address this issue.
@@ -113 +113 @@
 However, this third challenge is outside the scope of this thesis because developing a general heuristic is complex enough to justify its own work.
 Therefore, the \CFA scheduler simply follows the ``Race-to-Idle''~\cite{Albers12} approach where a sleeping \proc is woken any time a \at becomes ready and \procs go to idle sleep anytime they run out of work.
+An interesting sub-part of this heuristic is what to do with bursts of \ats that become ready.
+Since waking up a sleeping \proc can have notable latency, it is possible multiple \ats become ready while a single \proc is waking up.
+This facts begs the question, if many \procs are available, how many should be woken?
+If the ready \ats will run longer than the wake-up latency, waking one \proc per \at will offer maximum parallelisation.
+If the ready \ats will run for a short very short time, waking many \procs may be wasteful.
+As mentioned, a heuristic to handle these complex cases is outside the scope of this thesis, the behaviour of the scheduler in this particular case is left unspecified.
 
 \section{Sleeping}
@@ -200 +206 @@
 Notifiers that obtained a @NULL@ in the exchange simply move on knowing that another notifier is already waking a \proc.
 This behaviour is equivalent to having multiple notifier write to the @fd@ since reads consume all previous writes.
+Note that with and without this atomic pointer, bursts of notification can lead to an unspecified number of \procs being woken up, depending on how the arrival notification compares witht the latency of \procs waking up.
+As mentioned in section~\ref{idlesleep}, there is no optimal approach to handle these bursts.
+It is therefore difficult to justify the cost of any extra synchronization here.
 
 \begin{figure}[t]