Ignore:
Timestamp:
Jul 25, 2022, 11:47:32 AM (2 years ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
ADT, ast-experimental, master, pthread-emulation, qualifiedEnum
Children:
970fa54
Parents:
1988572
Message:

added some discussion on heuristic and burst wake-up

File:
1 edited

Legend:

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

    r1988572 r6a6544d  
    9797\end{figure}
    9898
    99 \section{Idle-Sleep}
     99\section{Idle-Sleep}\label{idlesleep}
    100100While 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.
    101101For 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.
     
    113113However, this third challenge is outside the scope of this thesis because developing a general heuristic is complex enough to justify its own work.
    114114Therefore, 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.
     115An interesting sub-part of this heuristic is what to do with bursts of \ats that become ready.
     116Since waking up a sleeping \proc can have notable latency, it is possible multiple \ats become ready while a single \proc is waking up.
     117This facts begs the question, if many \procs are available, how many should be woken?
     118If the ready \ats will run longer than the wake-up latency, waking one \proc per \at will offer maximum parallelisation.
     119If the ready \ats will run for a short very short time, waking many \procs may be wasteful.
     120As 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.
    115121
    116122\section{Sleeping}
     
    199205Notifiers that obtained a @NULL@ in the exchange simply move on, knowing that another notifier is already waking a \proc.
    200206This behaviour is equivalent to having multiple notifier write to the @fd@ since reads consume all previous writes.
     207Note 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.
     208As mentioned in section~\ref{idlesleep}, there is no optimal approach to handle these bursts.
     209It is therefore difficult to justify the cost of any extra synchronization here.
    201210
    202211\begin{figure}[t]
Note: See TracChangeset for help on using the changeset viewer.