Changeset d93ea1d for doc/theses/thierry_delisle_PhD

Timestamp:

Aug 15, 2022, 5:06:43 PM (2 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

e116db3

Parents:

8bee858

Message:

Filled in something for the conclusion that is kind of complete

File:

• doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex (modified) (1 diff)

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

@@ -19 +19 @@
 
 \subsection{Idle Sleep}
-An interesting
+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.