Changeset 7a0f798b for doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex

Timestamp:

Sep 6, 2022, 4:05:00 PM (2 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

a44514e

Parents:

9f99799

Message:

Merged peter's last changes and filled in most of the TODOs

File:

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

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

@@ -13 +13 @@
 A MQMS scheduler, with its \proc-specific ready-queues, has poor load-balancing but perfect affinity often resulting in significantly reduced communication.
 However, implementing fairness for an MQMS scheduler is difficult, since fairness requires \procs to be aware of each other's ready-queue progress, \ie communicated knowledge.
-% This challenge is made harder when comparing against MQMS schedulers (see Section\ref{sched}) which have very little inter-\proc communication.
-For balanced workloads with little or no data sharing (embarrassingly parallel), an MQMS scheduler is near optimal, \eg state-of-the-art work-stealing schedulers.
+For balanced workloads with little or no data sharing (embarrassingly parallel), an MQMS scheduler, \eg a state-of-the-art work-stealing scheduler, is near optimal.
 For these kinds of fair workloads, adding fairness must be low-cost to hide the communication costs needed for global ready-queue progress or performance suffers.
+While I was aware of these realities, I underestimated how little performance margin there is for communication.
+Several of my attempts at building a fair scheduler compared poorly to work-stealing schedulers because of how thin the margin is.
 
 Second, the kernel locking, threading, and I/O in the Linux operating system offers very little flexibility, and are not designed to facilitate user-level threading.