source: doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex @ 50ff1d0

\chapter{Conclusion}\label{conclusion}

\Gls{uthrding} is popular.
It makes sense for \CFA to use it.

\todo{Obivously fix the above}

An important aspect of this approach to threading is how threads are scheduled.
As \CFA aims to increase productivity and safety of C while maintaining its performance, so to should the threading runtime achieve these goals.
For scheduling, productivity and safety manifest in removing pitfalls in the efficient usage of the threading runtime.
This thesis contributes to this goal by presenting a low-latency scheduler that offers improved starvation prevention compared to other state-of-the-art schedulers.
It presents a core algorithm (Chapter~\ref{core}) that provides increased fairness through helping (Section~\ref{heling}) as well as optimizations which virtually remove the cost of this fairness (Section~\ref{relaxedtimes}).
Building upon the fundamental scheduling algorithm, an implementation of user-level \io blocking is presented (Chapter~\ref{io}) which achieves the same performance and fairness balance as the scheduler itself.
From these core algorithms, and a low-latency idle-sleep mechanism is presented (Chapter~\ref{practice}) which allows the \CFA runtime to stay viable for workloads that do not consistently saturate the system.

\section{Future Work}
While the \CFA runtime achieves a better compromise in term of performance and fairness than other schedulers, I do believe that further improvements could be made to reduce even further the number of cases where performance deteriorates.
Furthermore, I believe that achieve performance and starvation freedom simultaneously is generally a challenge even outside of scheduling algorithms.

\subsection{Idle Sleep}
A difficult challenge that was not fully address in this thesis is idle-sleep.
While a correct and somewhat low-cost idle-sleep mechanism was presented, several of the benchmarks show notable performance degradation when too few \ats are present in the system.
The idle sleep mechanism could therefore benefit from a reduction of spurious cases of sleeping.
Furthermore, this thesis did not present any heuristic for when \procs should be put to sleep and when \procs should be woken up.
It is especially worth noting that relaxed timestamps and topology aware helping lead to notable improvements in performance.
Neither of these techniques were used for the idle sleep mechanism.

There are opportunities where these techniques could be use:
The mechanism uses a hand-shake between notification and sleep to ensure that no \at is missed.
The correctness of that hand-shake is cirtical when the last \proc goes to sleep but could be relaxed when several \procs are awake.
Furthermore, organizing the sleeping \procs as a LIDO stack makes sense to keep cold \procs as cold as possible, but it might be more appropriate to attempt to keep cold CPU sockets instead.

However, using these techniques could require significant investigation.
For example, keeping a CPU socket cold might be appropriate for power consumption reasons but can affect overall memory bandwith.
The balance between these is not necessarily obvious.

\subsection{Hardware}
One challenge that needed to be overcome for this thesis was that the modern x86-64 has very few tools to implement fairness.
\Glspl{proc} attempting to help eachother inherently cause cache-coherence traffic.
However, as mentioned in Section~\ref{helping}, relaxed requirements mean this traffic is not necessarily productive.
In cases like this one, there is an opportunity to improve performance by extending the hardware.

Many different extensions would be suitable here.
For example, when attempting to read remote timestamps when deciding to whether or not to help, it could be useful to allow cancelling the remote read if it will lead to significant latency.
If the latency is due to a recent cache invalidation, it is unlikely that the timestamp is old and that helping will be needed.
As such, simply moving on without the result is likely to be acceptable.
Another option would be to attempt to read multiple memory addresses and only wait for \emph{one of} these reads to retire.
This would have a similar effect, where cache-lines with more traffic would be waited on less often.
In both of these examples, some care would probably be needed to make sure that the reads to an address \emph{sometimes} retire.

Note that this is similar to the feature \newterm{Hardware Transactional Memory}~\cite{HTM}, which allows groups of instructions to be aborted and rolled-back if they encounter memory conflicts when being retired.
However, I believe this feature is generally aimed at large groups of instructions.
A more fine-grained approach may be more amenable to carefully picking which aspects of an algorithm require exact correctness and which do not.