Index: doc/theses/thierry_delisle_PhD/comp_II/Makefile =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/Makefile (revision 61b14476b305db14a7e5d99fed4f7b22928d8836) +++ doc/theses/thierry_delisle_PhD/comp_II/Makefile (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -12,20 +12,15 @@ ## Define the text source files. - -SOURCES = ${addsuffix .tex, \ -comp_II \ -} - FIGURES = ${addsuffix .tex, \ - base \ - empty \ emptybit \ emptytree \ emptytls \ resize \ - system \ } PICTURES = ${addsuffix .pstex, \ + base \ + empty \ + system \ } @@ -37,6 +32,9 @@ ## Define the documents that need to be made. +all: comp_II.pdf presentation.pdf +comp_II.pdf: ${FIGURES} ${PICTURES} +presentation.pdf: presentationstyle.sty base.dark.pstex empty.dark.pstex system.dark.pstex -DOCUMENT = comp_II.pdf +DOCUMENT = comp_II.pdf presentation.pdf BASE = ${basename ${DOCUMENT}} @@ -52,23 +50,21 @@ # File Dependencies # -${DOCUMENT} : ${BASE}.ps +%.pdf : build/%.ps | ${Build} ps2pdf $< -${BASE}.ps : ${BASE}.dvi - dvips ${Build}/$< -o $@ +build/%.ps : build/%.dvi | ${Build} + dvips $< -o $@ -${BASE}.dvi : Makefile ${GRAPHS} ${PROGRAMS} ${PICTURES} ${FIGURES} ${SOURCES} \ - ${Macros}/common.tex ${Macros}/indexstyle ../../../bibliography/pl.bib \ - local.bib glossary.tex | ${Build} +build/%.dvi : %.tex Makefile | ${Build} # Must have *.aux file containing citations for bibtex - if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} ${basename $@}.tex ; fi - -${BibTeX} ${Build}/${basename $@} + if [ ! -r ${basename $@}.aux ] ; then ${LaTeX} $< ; fi + -${BibTeX} ${basename $@} # Some citations reference others so run again to resolve these citations - ${LaTeX} ${basename $@}.tex - -${BibTeX} ${Build}/${basename $@} + ${LaTeX} $< + -${BibTeX} ${basename $@} # Make index from *.aux entries and input index at end of document - makeglossaries -q -s ${Build}/${basename $@}.ist ${Build}/${basename $@} + -makeglossaries -q -s ${basename $@}.ist ${basename $@} # Run again to finish citations - ${LaTeX} ${basename $@}.tex + ${LaTeX} $< ## Define the default recipes. @@ -77,5 +73,5 @@ mkdir -p ${Build} -%.tex : img/%.fig ${Build} +%.tex : img/%.fig | ${Build} fig2dev -L eepic $< > ${Build}/$@ @@ -87,4 +83,12 @@ fig2dev -L pstex_t -p ${Build}/$@ $< > ${Build}/$@_t +## pstex with inverted colors +%.dark.pstex : img/%.fig Makefile | ${Build} + fig2dev -L pstex $< > ${Build}/$@ + sed -i 's/\/col-1 {0 setgray} bind def/\/col-1 {1 setgray} bind def/g' ${Build}/$@ + sed -i 's/\/col0 {0.000 0.000 0.000 srgb} bind def/\/col0 {1.000 1.000 1.000 srgb} bind def/g' ${Build}/$@ + sed -i 's/\/col7 {1.000 1.000 1.000 srgb} bind def/\/col7 {0.000 0.000 0.000 srgb} bind def/g' ${Build}/$@ + fig2dev -L pstex_t -p ${Build}/$@ $< > ${Build}/$@_t + # Local Variables: # # compile-command: "make" # Index: doc/theses/thierry_delisle_PhD/comp_II/comp_II.tex =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/comp_II.tex (revision 61b14476b305db14a7e5d99fed4f7b22928d8836) +++ doc/theses/thierry_delisle_PhD/comp_II/comp_II.tex (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -63,5 +63,5 @@ It aims to add high-productivity features while maintaining the predictable performance of C. As such, concurrency in \CFA\cite{Delisle19} aims to offer simple and safe high-level tools while still allowing performant code. -\CFA concurrent code is written in the synchronous programming paradigm but uses \glspl{uthrd} in order to achieve the simplicity and maintainability of synchronous programming without sacrificing the efficiency of asynchronous programing. +\CFA concurrent code is written in the synchronous programming paradigm but uses \glspl{uthrd} in order to achieve the simplicity and maintainability of synchronous programming without sacrificing the efficiency of asynchronous programming. As such, the \CFA \newterm{scheduler} is a preemptive user-level scheduler that maps \glspl{uthrd} onto \glspl{kthrd}. @@ -75,7 +75,6 @@ and the cost of scheduling, \ie deciding which thread to run next among all the threads ready to run. \end{enumerate} -The first cost is generally constant and fixed\footnote{Affecting the constant context-switch cost is whether it is done in one step, after the scheduling, or in two steps, context-switching to a fixed third-thread before scheduling.}, while the scheduling cost can vary based on the system state. -Adding multiple \glspl{kthrd} does not fundamentally change the scheduler semantics or requirements, it simply adds new correctness requirements, \ie \newterm{linearizability}\footnote{Meaning however fast the CPU threads run, there is an equivalent sequential order that gives the same result.}, and a new dimension to performance: scalability, where scheduling cost now also depends on contention. - +The first cost is generally constant and fixed\footnote{Affecting the constant context-switch cost is whether it is done in one step, after the scheduling, or in two steps, context-switching to a third fixed thread before scheduling.}, while the scheduling cost can vary based on the system state. +Adding multiple \glspl{kthrd} does not fundamentally change the scheduler semantics or requirements, it simply adds new correctness requirements, \ie \newterm{linearizability}\footnote{Meaning, however fast the CPU threads run, there is an equivalent sequential order that gives the same result.}, and a new dimension to performance: scalability, where scheduling cost now also depends on contention. The more threads switch, the more the administration cost of scheduling becomes noticeable. It is therefore important to build a scheduler with the lowest possible cost and latency. @@ -84,5 +83,5 @@ While the illusion of simultaneity is easier to reason about, it can break down if the scheduler allows too much unfairness. Therefore, the scheduler should offer as much fairness as needed to guarantee eventual progress, but use unfairness to help performance. -In practice, threads must wait in turn but there can be advantages to unfair scheduling, similar to the the express cash-register at a grocery store. +In practice, threads must wait in turn but there can be advantages to unfair scheduling, similar to the express cash register at a grocery store. The goal of this research is to produce a scheduler that is simple for programmers to understand and offers good performance. @@ -93,6 +92,6 @@ \end{quote} -For a general purpose scheduler, it is impossible to produce an optimal algorithm as it would require knowledge of the future behaviour of threads. -As such, scheduling performance is generally either defined by the best case scenario, \ie a workload to which the scheduler is tailored, or the worst case scenario, \ie the scheduler behaves no worst than \emph{X}. +For a general-purpose scheduler, it is impossible to produce an optimal algorithm as it would require knowledge of the future behaviour of threads. +As such, scheduling performance is generally either defined by the best-case scenario, \ie a workload to which the scheduler is tailored, or the worst-case scenario, \ie the scheduler behaves no worse than \emph{X}. For this proposal, the performance is evaluated using the second approach to allow \CFA programmers to rely on scheduling performance. Because there is no optimal scheduler, ultimately \CFA may allow programmers to write their own scheduler; but that is not the subject of this proposal, which considers only the default scheduler. @@ -101,12 +100,8 @@ To achieve the \CFA scheduling goal includes: \begin{enumerate} -\item -producing a scheduling strategy with sufficient fairness guarantees, -\item -creating an abstraction layer over the operating system to handle kernel-threads spinning unnecessarily, -\item -scheduling blocking I/O operations, -\item -and writing sufficient library tools to allow developers to indirectly use the scheduler, either through tuning knobs or replacing the default scheduler. + \item producing a scheduling strategy with sufficient fairness guarantees, + \item creating an abstraction layer over the operating system to handle kernel-threads spinning unnecessarily, + \item scheduling blocking I/O operations, + \item and writing sufficient library tools to allow developers to indirectly use the scheduler, either through tuning knobs or replacing the default scheduler. \end{enumerate} @@ -119,5 +114,5 @@ \paragraph{Correctness} As with any other concurrent data structure or algorithm, the correctness requirement is paramount. The scheduler cannot allow threads to be dropped from the ready queue, \ie scheduled but never run, or be executed multiple times when only being scheduled once. -Since \CFA concurrency has no spurious wakeup, this definition of correctness also means the scheduler should have no spurious wakeup. +Since \CFA concurrency has no spurious wake up, this definition of correctness also means the scheduler should have no spurious wake up. The \CFA scheduler must be correct. @@ -130,9 +125,9 @@ The \CFA scheduler should offer good performance for all three metrics. -\paragraph{Fairness} Like performance, this requirement has several aspect : eventual progress, predictability and performance reliability. +\paragraph{Fairness} Like performance, this requirement has several aspects : eventual progress, predictability and performance reliability. \newterm{Eventual progress} guarantees every scheduled thread is eventually run, \ie prevent starvation. -As a hard requirement, the \CFA scheduler must guarantee eventual progress, otherwise the above mentioned illusion of simultaneous execution is broken and the scheduler becomes much more complex to reason about. -\newterm{Predictability} and \newterm{reliability} means similar workloads achieve similar performance and programmer execution intuition is respected. -For example, a thread that yields aggressively should not run more often then other tasks. +As a hard requirement, the \CFA scheduler must guarantee eventual progress, otherwise the above-mentioned illusion of simultaneous execution is broken and the scheduler becomes much more complex to reason about. +\newterm{Predictability} and \newterm{reliability} mean similar workloads achieve similar performance and programmer execution intuition is respected. +For example, a thread that yields aggressively should not run more often than other tasks. While this is intuitive, it does not hold true for many work-stealing or feedback based schedulers. The \CFA scheduler must guarantee eventual progress and should be predictable and offer reliable performance. @@ -150,5 +145,5 @@ \begin{enumerate} - \item Threads live long enough for useful feedback information to be to gathered. + \item Threads live long enough for useful feedback information to be gathered. \item Threads belong to multiple users so fairness across threads is insufficient. \end{enumerate} @@ -157,5 +152,5 @@ Since \CFA has the explicit goal of allowing many smaller threads, this can naturally lead to threads with much shorter lifetimes that are only scheduled a few times. Scheduling strategies based on feedback cannot be effective in these cases because there is no opportunity to measure the metrics that underlie the algorithm. -Note, the problem of \newterm{feedback convergence} (reacting too slowly to scheduling events) is not specific to short lived threads but can also occur with threads that show drastic changes in scheduling, \eg threads running for long periods of time and then suddenly blocking and unblocking quickly and repeatedly. +Note, the problem of \newterm{feedback convergence} (reacting too slowly to scheduling events) is not specific to short-lived threads but can also occur with threads that show drastic changes in scheduling, \eg threads running for long periods of time and then suddenly blocking and unblocking quickly and repeatedly. In the context of operating systems, these concerns can be overshadowed by a more pressing concern : security. @@ -164,5 +159,5 @@ In the case of the \CFA scheduler, every thread runs in the same user space and is controlled by the same user. Fairness across users is therefore a given and it is then possible to safely ignore the possibility that threads are malevolent. -This approach allows for a much simpler fairness metric and in this proposal \emph{fairness} is defined as: when multiple threads are cycling through the system, the total ordering of threads being scheduled, \ie pushed onto the ready-queue, should not differ much from the total ordering of threads being executed, \ie popped from the ready-queue. +This approach allows for a much simpler fairness metric and in this proposal \emph{fairness} is defined as: when multiple threads are cycling through the system, the total ordering of threads being scheduled, \ie pushed onto the ready queue, should not differ much from the total ordering of threads being executed, \ie popped from the ready queue. Since feedback is not necessarily feasible within the lifetime of all threads and a simple fairness metric can be used, the scheduling strategy proposed for the \CFA runtime does not use per-threads feedback. @@ -172,10 +167,10 @@ Another broad category of schedulers are priority schedulers. In these scheduling strategies, threads have priorities and the runtime schedules the threads with the highest priority before scheduling other threads. -Threads with equal priority are scheduled using a secondary strategy, often something simple like round-robin or FIFO. +Threads with equal priority are scheduled using a secondary strategy, often something simple like round robin or FIFO. A consequence of priority is that, as long as there is a thread with a higher priority that desires to run, a thread with a lower priority does not run. This possible starving of threads can dramatically increase programming complexity since starving threads and priority inversion (prioritizing a lower priority thread) can both lead to serious problems. An important observation is that threads do not need to have explicit priorities for problems to occur. -Indeed, any system with multiple ready-queues that attempts to exhaust one queue before accessing the other queues, essentially provide implicit priority, which can encounter starvation problems. +Indeed, any system with multiple ready queues that attempts to exhaust one queue before accessing the other queues, essentially provide implicit priority, which can encounter starvation problems. For example, a popular scheduling strategy that suffers from implicit priorities is work stealing. \newterm{Work stealing} is generally presented as follows: @@ -191,5 +186,5 @@ \subsection{Schedulers without feedback or priorities} -This proposal conjectures that is is possible to construct a default scheduler for the \CFA runtime that offers good scalability and a simple fairness guarantee that is easy for programmers to reason about. +This proposal conjectures that it is possible to construct a default scheduler for the \CFA runtime that offers good scalability and a simple fairness guarantee that is easy for programmers to reason about. The simplest fairness guarantee is FIFO ordering, \ie threads scheduled first run first. However, enforcing FIFO ordering generally conflicts with scalability across multiple processors because of the additional synchronization. @@ -217,5 +212,5 @@ Pushing new data is done by selecting one of these underlying queues at random, recording a timestamp for the operation and pushing to the selected queue. Popping is done by selecting two queues at random and popping from the queue with the oldest timestamp. -A higher number of underlying queues leads to less contention on each queue and therefore better performance. +A higher number of underlying queues lead to less contention on each queue and therefore better performance. In a loaded system, it is highly likely the queues are non-empty, \ie several tasks are on each of the underlying queues. This means that selecting a queue at random to pop from is highly likely to yield a queue with available items. @@ -224,8 +219,8 @@ \begin{figure} \begin{center} - \input{base} + \input{base.pstex_t} \end{center} \caption{Relaxed FIFO list at the base of the scheduler: an array of strictly FIFO lists. -The timestamp is in all nodes and cell arrays.} + The timestamp is in all nodes and cell arrays.} \label{fig:base} \end{figure} @@ -233,5 +228,5 @@ \begin{figure} \begin{center} - \input{empty} + \input{empty.pstex_t} \end{center} \caption{``More empty'' state of the queue: the array contains many empty cells.} @@ -245,5 +240,5 @@ Overall performance is therefore influenced by the contention on the underlying queues and pop performance is influenced by the item density. -This leads to four performance cases for the centralized ready-queue, as depicted in Table~\ref{tab:perfcases}. +This leads to four performance cases for the centralized ready queue, as depicted in Table~\ref{tab:perfcases}. The number of processors (many or few) refers to the number of kernel threads \emph{actively} attempting to pop user threads from the queues, not the total number of kernel threads. The number of threads (many or few) refers to the number of user threads ready to be run. @@ -321,6 +316,6 @@ Sparse global information helps high-contention cases but increases latency in zero-contention-cases, to read and ``aggregate'' the information\footnote{Hierarchical structures, \eg binary search tree, effectively aggregate information but follow pointer chains, learning information at each node. Similarly, other sparse schemes need to read multiple cachelines to acquire all the information needed.}. -Finally, dense local information has both the advantages of low latency in zero-contention cases and scalability in high-contention cases, however the information can become stale making it difficult to use to ensure correctness. -The fact that these solutions have these fundamental limits suggest to me a better solution that attempts to combine these properties in an interesting ways. +Finally, dense local information has both the advantages of low latency in zero-contention cases and scalability in high-contention cases. However the information can become stale making it difficult to use to ensure correctness. +The fact that these solutions have these fundamental limits suggest to me a better solution that attempts to combine these properties in an interesting way. Also, the lock discussed in Section~\ref{sec:resize} allows for solutions that adapt to the number of processors, which could also prove useful. @@ -328,9 +323,9 @@ How much scalability is actually needed is highly debatable. -\emph{libfibre}\cite{libfibre} has compared favorably to other schedulers in webserver tests\cite{Karsten20} and uses a single atomic counter in its scheduling algorithm similarly to the proposed bitmask. +\emph{libfibre}\cite{libfibre} has compared favourably to other schedulers in webserver tests\cite{Karsten20} and uses a single atomic counter in its scheduling algorithm similarly to the proposed bitmask. As such, the single atomic instruction on a shared cacheline may be sufficiently performant. I have built a prototype of this ready queue in the shape of a data queue, \ie nodes on the queue are structures with a single int representing a thread and intrusive data fields. -Using this prototype I ran preliminary performance experiments that confirm the expected performance in Table~\ref{tab:perfcases}. +Using this prototype, I ran preliminary performance experiments that confirm the expected performance in Table~\ref{tab:perfcases}. However, these experiments only offer a hint at the actual performance of the scheduler since threads form more complex operations than simple integer nodes, \eg threads are not independent of each other, when a thread blocks some other thread must intervene to wake it. @@ -341,5 +336,5 @@ \begin{figure} \begin{center} - \input{system} + \input{system.pstex_t} \end{center} \caption{Global structure of the \CFA runtime system.} @@ -354,5 +349,5 @@ This assumption is made both in the design of the proposed scheduler as well as in the original design of the \CFA runtime system. As such, the proposed scheduler must honour the correctness of this behaviour but does not have any performance objectives with regard to resizing a cluster. -How long adding or removing processors take and how much this disrupts the performance of other threads is considered a secondary concern since it should be amortized over long period of times. +How long adding or removing processors take and how much this disrupts the performance of other threads is considered a secondary concern since it should be amortized over long periods of times. However, as mentioned in Section~\ref{sec:queue}, contention on the underlying queues can have a direct impact on performance. The number of underlying queues must therefore be adjusted as the number of processors grows or shrinks. @@ -372,5 +367,5 @@ This description effectively matches with the description of a reader-writer lock, infrequent but invasive updates among frequent read operations. In the case of the ready queue described above, read operations are operations that push or pop from the ready queue but do not invalidate any references to the ready queue data structures. -Writes on the other hand would add or remove inner queues, invalidating references to the array of inner queues in a process. +Writes, on the other hand, would add or remove inner queues, invalidating references to the array of inner queues in a process. Therefore, the current proposed approach to this problem is to add a per-cluster reader-writer lock around the ready queue to prevent restructuring of the ready-queue data-structure while threads are being pushed or popped. @@ -380,5 +375,5 @@ \paragraph{Objectives and Existing Work} -The lock must offer scalability and performance on par with the actual ready-queue in order not to introduce a new bottleneck. +The lock must offer scalability and performance on par with the actual ready queue in order not to introduce a new bottleneck. I have already built a lock that fits the desired requirements and preliminary testing show scalability and performance that exceed the target. As such, I do not consider this lock to be a risk for this project. @@ -396,5 +391,5 @@ give back unneeded CPU time associated with a process to other user processors executing on the computer, \item -and reduce energy consumption in cases where more idle kernel-threads translate to idle CPUs, which can cycle down. +and reduce energy consumption in cases where more idle kernel-threads translate into idle CPUs, which can cycle down. \end{enumerate} Support for idle sleep broadly involves calling the operating system to block the kernel thread and handling the race between a blocking thread and the waking thread, and handling which kernel thread should sleep or wake up. @@ -403,5 +398,5 @@ This operation is equivalent to the classic problem of missing signals when using condition variables: the ``sleepy'' processor indicates its intention to block but has not yet gone to sleep when another processor attempts to wake it up. The waking-up operation sees the blocked process and signals it, but the blocking process is racing to sleep so the signal is missed. -In cases where kernel threads are managed as processors on the current cluster, loosing signals is not necessarily critical, because at least some processors on the cluster are awake and may check for more processors eventually. +In cases where kernel threads are managed as processors on the current cluster, losing signals is not necessarily critical, because at least some processors on the cluster are awake and may check for more processors eventually. Individual processors always finish scheduling user threads before looking for new work, which means that the last processor to go to sleep cannot miss threads scheduled from inside the cluster (if they do, that demonstrates the ready queue is not linearizable). However, this guarantee does not hold if threads are scheduled from outside the cluster, either due to an external event like timers and I/O, or due to a user (or kernel) thread migrating from a different cluster. @@ -413,5 +408,5 @@ Another important issue is avoiding kernel threads sleeping and waking frequently because there is a significant operating-system cost. -This scenario happens when a program oscillates between high and low activity, needing most and then less processors. +This scenario happens when a program oscillates between high and low activity, needing most and then fewer processors. A possible partial solution is to order the processors so that the one which most recently went to sleep is woken up. This allows other sleeping processors to reach deeper sleep state (when these are available) while keeping ``hot'' processors warmer. @@ -420,6 +415,6 @@ A final important aspect of idle sleep is when should processors make the decision to sleep and when is it appropriate for sleeping processors to be woken up. -Processors that are unnecessarily unblocked lead to unnecessary contention, CPU usage, and power consumption, while too many sleeping processors can lead to sub-optimal throughput. -Furthermore, transitions from sleeping to awake and vice-versa also add unnecessary latency. +Processors that are unnecessarily unblocked lead to unnecessary contention, CPU usage, and power consumption, while too many sleeping processors can lead to suboptimal throughput. +Furthermore, transitions from sleeping to awake and vice versa also add unnecessary latency. There is already a wealth of research on the subject\cite{schillings1996engineering, wiki:thunderherd} and I may use an existing approach for the idle-sleep heuristic in this project, \eg\cite{Karsten20}. @@ -430,5 +425,5 @@ It is preferable to block the user thread performing the I/O and reuse the underlying kernel-thread to run other ready user threads. This approach requires intercepting user-thread calls to I/O operations, redirecting them to an asynchronous I/O interface, and handling the multiplexing/demultiplexing between the synchronous and asynchronous API. -As such, there are three components needed to implemented support for asynchronous I/O: +As such, there are three components needed to implement support for asynchronous I/O: \begin{enumerate} \item @@ -446,20 +441,20 @@ It is sufficient to make one work in the complex context of the \CFA runtime. \uC uses the $select$\cite{select} as its interface, which handles ttys, pipes and sockets, but not disk. -$select$ entails significant complexity and is being replaced in UNIX operating-systems, which make it a less interesting alternative. +$select$ entails significant complexity and is being replaced in UNIX operating systems, which make it a less interesting alternative. Another popular interface is $epoll$\cite{epoll}, which is supposed to be cheaper than $select$. -However, $epoll$ also does not handle the file system and anectodal evidence suggest it has problem with linux pipes and $TTY$s. +However, $epoll$ also does not handle the file system and anecdotal evidence suggest it has problems with Linux pipes and $TTY$s. A popular cross-platform alternative is $libuv$\cite{libuv}, which offers asynchronous sockets and asynchronous file system operations (among other features). However, as a full-featured library it includes much more than I need and could conflict with other features of \CFA unless significant effort is made to merge them together. A very recent alternative that I am investigating is $io_uring$\cite{io_uring}. -It claims to address some of the issues with $epoll$ and my early investigating suggest that the claim is accurate. -$io_uring$ uses a much more general approach where system calls are register to a queue and later executed by the kernel, rather than relying on system calls to return an error instead of blocking and subsequently waiting for changes on file descriptors. +It claims to address some of the issues with $epoll$ and my early investigating suggests that the claim is accurate. +$io_uring$ uses a much more general approach where system calls are registered to a queue and later executed by the kernel, rather than relying on system calls to return an error instead of blocking and subsequently waiting for changes on file descriptors. I believe this approach allows for fewer problems, \eg the manpage for $open$\cite{open} states: \begin{quote} - Note that [the $O_NONBLOCK$ flag] has no effect for regular files and block devices; - that is, I/O operations will (briefly) block when device activity is required, regardless of whether $O_NONBLOCK$ is set. - Since $O_NONBLOCK$ semantics might eventually be implemented, applications should not depend upon blocking behavior when specifying this flag for regular files and block devices. +Note that [the $O_NONBLOCK$ flag] has no effect for regular files and block devices; +that is, I/O operations will (briefly) block when device activity is required, regardless of whether $O_NONBLOCK$ is set. +Since $O_NONBLOCK$ semantics might eventually be implemented, applications should not depend upon blocking behaviour when specifying this flag for regular files and block devices. \end{quote} This makes approach based on $epoll$/$select$ less reliable since they may not work for every file descriptors. -For this reason, I plan to use $io_uring$ as the OS abstraction for the \CFA runtime, unless further work shows problems I haven't encountered yet. +For this reason, I plan to use $io_uring$ as the OS abstraction for the \CFA runtime unless further work shows problems I haven't encountered yet. However, only a small subset of the features are available in Ubuntu as of April 2020\cite{wiki:ubuntu-linux}, which will limit performance comparisons. I do not believe this will affect the comparison result. @@ -490,5 +485,5 @@ \section{Discussion} I believe that runtime system and scheduling are still open topics. -Many ``state of the art'' production frameworks still use single threaded event-loops because of performance considerations, \eg \cite{nginx-design}, and, to my knowledge, no wideyl available system language offers modern threading facilities. +Many ``state of the art'' production frameworks still use single-threaded event loops because of performance considerations, \eg \cite{nginx-design}, and, to my knowledge, no widely available system language offers modern threading facilities. I believe the proposed work offers a novel runtime and scheduling package, where existing work only offers fragments that users must assemble themselves when possible. @@ -501,5 +496,5 @@ \hline November 2020 & March 2021 & Completion of the implementation. \\ \hline March 2021 & April 2021 & Final Performance experiments. \\ -\hline May 2021 & August 2021 & Thesis writing and defense. \\ +\hline May 2021 & August 2021 & Thesis writing and defence. \\ \hline \end{tabular} Index: doc/theses/thierry_delisle_PhD/comp_II/img/base.fig =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/img/base.fig (revision 61b14476b305db14a7e5d99fed4f7b22928d8836) +++ doc/theses/thierry_delisle_PhD/comp_II/img/base.fig (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -1,7 +1,7 @@ -#FIG 3.2 Produced by xfig version 3.2.5c +#FIG 3.2 Produced by xfig version 3.2.7b Landscape Center Inches -Letter +Letter 100.00 Single @@ -13,16 +13,4 @@ 1 3 0 1 0 0 50 -1 20 0.000 1 0.0000 6975 4200 20 20 6975 4200 6995 4200 -6 -6 2400 2100 3000 2700 -1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2700 2400 300 300 2700 2400 3000 2400 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2400 2475 3000 2475 -4 1 0 50 -1 0 11 0.0000 2 120 210 2700 2650 TS\001 --6 -6 2400 3000 3000 3600 -1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2700 3300 300 300 2700 3300 3000 3300 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 - 2400 3375 3000 3375 -4 1 0 50 -1 0 11 0.0000 2 120 210 2700 3550 TS\001 --6 1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3900 2400 300 300 3900 2400 4200 2400 1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3900 3300 300 300 3900 3300 4200 3300 @@ -33,4 +21,6 @@ 1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 6300 3300 300 300 6300 3300 6600 3300 1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 4509 3302 300 300 4509 3302 4809 3302 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2700 3300 300 300 2700 3300 3000 3300 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2700 2400 300 300 2700 2400 3000 2400 2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 3000 3900 3000 4500 @@ -73,5 +63,5 @@ 1 1 1.00 45.00 90.00 6300 4200 6300 3600 -2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 +2 1 0 1 -1 7 50 -1 -1 0.000 0 0 -1 1 0 2 1 1 1.00 45.00 90.00 2700 4200 2700 3600 @@ -81,7 +71,13 @@ 1 1 1.00 45.00 90.00 4500 4200 4500 3600 -4 2 0 50 -1 0 12 0.0000 2 180 660 2100 4200 Array of\001 -4 2 0 50 -1 0 12 0.0000 2 165 600 2100 4425 Queues\001 -4 2 0 50 -1 0 12 0.0000 2 135 645 2100 3075 Threads\001 -4 2 0 50 -1 0 12 0.0000 2 180 525 2100 2850 Ready\001 -4 1 0 50 -1 0 11 0.0000 2 120 210 2700 4450 TS\001 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 3375 3000 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 2400 2475 3000 2475 +4 2 -1 50 -1 0 12 0.0000 2 135 630 2100 3075 Threads\001 +4 2 -1 50 -1 0 12 0.0000 2 165 450 2100 2850 Ready\001 +4 1 -1 50 -1 0 11 0.0000 2 135 180 2700 4450 TS\001 +4 2 -1 50 -1 0 12 0.0000 2 165 720 2100 4200 Array of\001 +4 2 -1 50 -1 0 12 0.0000 2 150 540 2100 4425 Queues\001 +4 1 -1 50 -1 0 11 0.0000 2 135 180 2700 3550 TS\001 +4 1 -1 50 -1 0 11 0.0000 2 135 180 2700 2650 TS\001 Index: doc/theses/thierry_delisle_PhD/comp_II/img/empty.fig =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/img/empty.fig (revision 61b14476b305db14a7e5d99fed4f7b22928d8836) +++ doc/theses/thierry_delisle_PhD/comp_II/img/empty.fig (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -1,7 +1,7 @@ -#FIG 3.2 Produced by xfig version 3.2.5c +#FIG 3.2 Produced by xfig version 3.2.7b Landscape Center Inches -Letter +Letter 100.00 Single @@ -41,6 +41,6 @@ 1 1 1.00 45.00 90.00 2700 4200 2700 3600 -4 2 0 50 -1 0 12 0.0000 2 180 660 2100 4200 Array of\001 -4 2 0 50 -1 0 12 0.0000 2 165 600 2100 4425 Queues\001 -4 2 0 50 -1 0 12 0.0000 2 135 645 2100 3075 Threads\001 -4 2 0 50 -1 0 12 0.0000 2 180 525 2100 2850 Ready\001 +4 2 -1 50 -1 0 12 0.0000 2 165 720 2100 4200 Array of\001 +4 2 -1 50 -1 0 12 0.0000 2 150 540 2100 4425 Queues\001 +4 2 -1 50 -1 0 12 0.0000 2 135 630 2100 3075 Threads\001 +4 2 -1 50 -1 0 12 0.0000 2 165 450 2100 2850 Ready\001 Index: doc/theses/thierry_delisle_PhD/comp_II/img/system.fig =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/img/system.fig (revision 61b14476b305db14a7e5d99fed4f7b22928d8836) +++ doc/theses/thierry_delisle_PhD/comp_II/img/system.fig (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -3,5 +3,5 @@ Center Inches -Letter +Letter 100.00 Single @@ -165,5 +165,5 @@ 4 1 -1 0 0 0 10 0.0000 2 105 990 2175 3525 Discrete-event\001 4 1 -1 0 0 0 10 0.0000 2 135 795 2175 4350 preemption\001 -4 0 -1 0 0 0 10 0.0000 2 150 1290 2325 4875 genrator/coroutine\001 +4 0 -1 0 0 0 10 0.0000 2 150 1290 2325 4875 generator/coroutine\001 4 0 -1 0 0 0 10 0.0000 2 120 270 4050 4875 task\001 4 0 -1 0 0 0 10 0.0000 2 105 450 7050 4875 cluster\001 Index: doc/theses/thierry_delisle_PhD/comp_II/presentation.tex =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/presentation.tex (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) +++ doc/theses/thierry_delisle_PhD/comp_II/presentation.tex (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -0,0 +1,343 @@ +\documentclass[english,aspectratio=169,svgnames,notes=hide,14pt,xcolor={dvipsnames}]{beamer} +\usepackage{graphicx} +\usepackage{epic,eepic} +\usepackage{presentationstyle} + +\title{The \CFA Scheduler} +\subtitle{PhD Comprehensive II Research Proposal} +\author{Thierry Delisle} +% \affil[1]{School of Computer Science, University of Waterloo} +% \affil[ ]{\textit {tdelisle@uwaterloo.ca}} + +\begin{document} +%============================== +\miniframesoff +\begin{frame}[noframenumbering,plain] + \titlepage +\end{frame} +%============================== +\section{Introduction} +%------------------------------ +\begin{frame}[noframenumbering] + \tableofcontents +\end{frame} +\miniframeson +%============================== +\AtBeginSection[]{ + \miniframesoff + \begin{frame} + \vfill + \centering + \begin{beamercolorbox}[sep=8pt,center,shadow=false,rounded=false]{title} + \usebeamerfont{title}\insertsectionhead\par% + \end{beamercolorbox} + \vfill + \end{frame} + \miniframeson +} +\section{\CFA and Concurrency} +\begin{frame}{\CFA} + +\end{frame} +%------------------------------ +\begin{frame}{Concurrency in \CFA} + User Level Threading + \begin{itemize} + \item M:N threading. + \item User Level Context Switching causes kernel-threads to run a different user-thread. + \end{itemize} + ~\newline + Threads organized in clusters: + \begin{itemize} + \item Clusters have their own kernel threads. + \item Threads in a cluster are on run on the kernel threads of that cluster. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Concurrency in \CFA} + \begin{table} + {\resizebox{1\textwidth}{!}{\input{system.dark.pstex_t}}} + \end{table} +\end{frame} +%------------------------------ +\begin{frame}{Scheduling goal for \CFA} + {\large + \begin{center} + The \CFA scheduler should be \textit{viable} for any workload. + \end{center} + } + ~\newline + This implies: + \begin{enumerate} + \item Producing a scheduler with sufficient fairness guarantees. + \item Handling kernel-threads running out of work. + \item Handling blocking I/O operations. + \end{enumerate} +\end{frame} +%============================== +\section{Scheduling in Practice} +%------------------------------ +\begin{frame}{In the Wild} + Schedulers found in production application generally fall into two categories: + \newline + + \begin{itemize} + \item Feedback Scheduling\newline + \item Priority Scheduling (explicit or not)\newline + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Feedback Scheduling} + Most operating systems based their scheduling on feedback loops. + ~\newline + + The scheduler runs a thread and adjusts some metric to choose when to run it, e.g., least CPU time first. + ~\newline + + Relies on the following assumptions: + \begin{enumerate} + \item Threads live long enough for useful feedback information to be to gathered. + \item Threads belong to multiple users so fairness across threads is insufficient. + \end{enumerate} +\end{frame} +%------------------------------ +\begin{frame}{Priority Scheduling} + \begin{center} + {\large + Runs all ready threads in group \textit{A} before any ready threads in group \textit{B}. + } + \end{center} + \vspace{1em} + + Explicit priorities: + \begin{itemize} + \item Threads given a priority at creation, e.g., Thread A has priority 1, Thread B has priority 6. + \end{itemize} + \vspace{0.75em} + + Implicit priorities: + \begin{itemize} + \item Certain threads are preferred, based on various metrics, e.g., last run, last run on this CPU. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Priority Scheduling: Work-Stealing} + Work-Stealing is a very popular strategy. + \begin{block}{Algorithm} + \begin{enumerate} + \item Each processor has a list of ready threads. + \item Each processor runs threads from its ready queue first. + \item If a processor's ready queue is empty, attempt to run threads from some other processor's ready queue. + \end{enumerate} + \end{block} + ~ + + Work-Stealing has implicit priorities: For a given processor, threads on it's queue have higher priority. + + Processors begin busy for long periods can mean starvation. +\end{frame} +%============================== +\section{Project: Proposal \& Details} +%------------------------------ +\begin{frame}{Central Ready-Queue} + \CFA will have a single ready-queue per cluster. + \newline + + The ready-queue will be sharded internally to reduce contention. + \newline + + No strong coupling between internal queues and processors. + \newline + + Constrasts with work-stealing which has a queue per processor. + \newline +\end{frame} +%------------------------------ +\begin{frame}{Central Ready-Queue} + \begin{table} + {\resizebox{0.8\textwidth}{!}{\input{base.dark.pstex_t}}} + \end{table} + ~ +\end{frame} +%------------------------------ +\begin{frame}{Central Ready-Queue Challenges} + \begin{columns} + \begin{column}{0.55\textwidth} + Semi-``Empty'' ready-queues means success rate of randomly guessing goes down. + \end{column} + \begin{column}{0.45\textwidth} + \begin{table} + {\resizebox{1\textwidth}{!}{\input{empty.dark.pstex_t}}} + \end{table} + \end{column} + \end{columns} + + Possible solutions: + \begin{itemize} + \item Data structure tracking the work, can be dense or sparse, global or sharded. + \item Add bias towards certain sub-queues. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Dynamic Resizing} + Processors can be added at anytime on a cluster. + \newline + + The array of queues needs to be adjusted in consequence. + \newline + + Solution: Global Reader-Writer lock + \begin{itemize} + \item Acquire for reading for normal scheduling operations. + \item Acquire for right when resizing the array and creating/deleting internal queues. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Idle Sleep} + Processors which cannot find threads to run should sleep, using \texttt{pthread\_cond\_wait}, \texttt{sigwaitinfo}, etc. + \newline + + Scheduling a thread may \textit{need} to wake sleeping processors. + \begin{itemize} + \item Threads can be scheduled from processors terminating or running outside the cluster. + In this case, all processors on the cluster could be sleeping. + \end{itemize} + ~ + + If \textit{some} processors are sleeping, waking more may be wasteful. + + A heuristic for this case is outside the scope of this project. +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O} + \begin{itemize} + \item I/O Operations should block user-threads rather than kernel-threads. \vspace{1cm} + \item This requires 3 components: + \begin{enumerate} + \item an OS abstraction layer over the asynchronous interface, \vspace{0.2cm} + \item an event-engine to (de)multiplex the operations, \vspace{0.2cm} + \item and a synchronous interface for users to use. \vspace{0.2cm} + \end{enumerate} + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: OS Abstraction} + \framesubtitle{\vskip0.5mm\large\texttt{select}} + \vskip5mm + + {\large ``select() allows a program to monitor multiple file descriptors, waiting until one + or more of the file descriptors become ``ready'' for some class of I/O operation.''} + + \hspace*\fill{\small--- Linux Programmer's Manual} + + \vskip5mm + \begin{itemize} + \item[+] moderate overhead per \texttt{syscall} + \item[-] Relies on \texttt{syscall}s returning \texttt{EWOULDBLOCK}. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: OS Abstraction} + \framesubtitle{\vskip0.5mm\large\texttt{epoll}} + \vskip2mm + + More recent system call with a similar purpose. + + \vskip5mm + \begin{itemize} + \item[+] Smaller overhead per \texttt{syscall}. + \item[+] Shown to work well for sockets. + \item[-] Still relies on \texttt{syscall}s returning \texttt{EWOULDBLOCK}. + \item[-] Does not support linux pipes and TTYs. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: OS Abstraction} + \framesubtitle{\vskip0.5mm\large Kernel Threads} + \vskip2mm + + Use a pool of kernel-threads, to which blocking calls are delegated. + + \vskip5mm + \begin{itemize} + \item Technique used by many existing systems, e.g., Go, libuv + \item[+] Definitely works for all \texttt{syscall}s. + \item[$-$] Can require many kernel threads. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: OS Abstraction} + \framesubtitle{\vskip0.5mm\large\texttt{io\_uring}} + \vskip2mm + + A very recent framework for asynchronous operations available in Linux 5.1 and later. + Uses two ring buffers to submit operations and poll completions. + + \vskip5mm + \begin{itemize} + \item[+] Handles many \texttt{syscall}s. + \item[+] Does \textit{not} rely on \texttt{syscall}s returning \texttt{EWOULDBLOCK}. + \item[$-$] Requires synchronization on submission. + \item[$-$] System call itself is serialized in the kernel. + \end{itemize} +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: Event Engine} + An event engine must be built to fit the chosen OS Abstraction. + \newline + + The engine must park user-threads until operation is completed. + \newline + + Depending on the chosen abstraction the engine may need to serialize operation submission. + \newline + + Throughput and latency are important metrics. +\end{frame} +%------------------------------ +\begin{frame}{Asynchronous I/O: The interface} + The Asynchronous I/O needs an interface. + \newline + + Several options to take into consideration: + \begin{itemize} + \item Adding to existing call interface, e.g., \texttt{read} and \texttt{cfaread}. \vspace{0.2cm} + \item Replacing existing call interface. \vspace{0.2cm} + \item True asynchronous interface, e.g., callbacks, futures. \vspace{0.2cm} + \end{itemize} + +\end{frame} +%============================== +\section{Conclusion} +%------------------------------ +\begin{frame}{Summary} + Runtime system and scheduling are still open topics. + \newline + + This work offers a novel runtime and scheduling package. + \newline + + Existing work only offers fragments that users must assemble themselves when possible. +\end{frame} +%------------------------------ +\begin{frame}{Timeline} + \begin{tabular}{ || m{0.1mm} m{0.75cm} m{1cm} | l } + % \hline + \phantom{100000cm} \phantom{100000cm} \phantom{100000cm} & {\small May Oct} & {\small 2020 2020} & Creation of the performance benchmark. \\ + \hline + \phantom{100000cm} \phantom{100000cm} \phantom{100000cm} & {\small Nov Mar} & {\small 2020 2021} & Completion of the implementation. \\ + \hline + \phantom{100000cm} \phantom{100000cm} \phantom{100000cm} & {\small Mar Apr} & {\small 2021 2021} & Final performance experiments. \\ + \hline + \phantom{100000cm} \phantom{100000cm} \phantom{100000cm} & {\small May Aug} & {\small 2021 2021} & Thesis writing and defense. \\ + % \hline + \end{tabular} +\end{frame} + +%------------------------------ +\begin{frame}{Timeline} + \begin{center} + {\large Questions?} + \end{center} +\end{frame} +\end{document} Index: doc/theses/thierry_delisle_PhD/comp_II/presentationstyle.sty =================================================================== --- doc/theses/thierry_delisle_PhD/comp_II/presentationstyle.sty (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) +++ doc/theses/thierry_delisle_PhD/comp_II/presentationstyle.sty (revision 8d8ac3bbf7435ae27e31e4195ddf5824bbe9c0da) @@ -0,0 +1,61 @@ +\usepackage{color} +\usepackage{xcolor} +\usepackage{xspace} +\usepackage{array} +\usepackage{stackengine} + +%============================== +% global theme +\usetheme[]{PaloAlto} +\usecolortheme[]{frigatebird} +% % • hideallsubsections causes only sections to be shown in the sidebar. This is useful, if you need to save space. +% % • hideothersubsections causes only the subsections of the current section to be shown. This is useful, if you need to save space. +% % • left puts the sidebar on the left (default). +% % • right puts the sidebar on the right. +% % • width=⟨dimension⟩ sets the width of the sidebar. If set to zero, no sidebar is created. +\useoutertheme[left,width=50pt]{sidebarwithminiframes} +\beamer@headheight = 1.25\baselineskip + +\setbeamertemplate{title page}[default][colsep=-4bp,rounded=false,shadow=false,left] +\setbeamertemplate{blocks}[rounded][shadow=false] +\newcommand\xrowht[2][0]{\addstackgap[.5\dimexpr#2\relax]{\vphantom{#1}}} + +%============================== +% Page numbers +\addtobeamertemplate{footline} +{% + \usebeamercolor[fg]{author in sidebar} + \vskip-1cm\hskip10pt + \insertframenumber\,/\,\inserttotalframenumber\kern1em\vskip2pt% +} + +%============================== +% Colors +\definecolor{colbg}{HTML}{282828} + +\setbeamercolor{palette primary}{bg=colbg} +\setbeamercolor{palette tertiary}{fg=red} + +%============================== +% Fix bullet points +\setbeamertemplate{itemize items}[default] +\setbeamertemplate{enumerate items}[default] + +%============================== +% cfa macros used in the document +\newcommand{\CFAIcon}{\textsf{C}\raisebox{\depth}{\rotatebox{180}{\textsf{A}}}\xspace} % Cforall symbolic name +\newcommand{\CFA}{\protect\CFAIcon} % safe for section/caption + +%============================== +% add option to disable miniframes +\makeatletter +\let\beamer@writeslidentry@miniframeson=\beamer@writeslidentry +\def\beamer@writeslidentry@miniframesoff{% + \expandafter\beamer@ifempty\expandafter{\beamer@framestartpage}{}% does not happen normally + {%else + \clearpage\beamer@notesactions% + } +} +\newcommand*{\miniframeson}{\let\beamer@writeslidentry=\beamer@writeslidentry@miniframeson} +\newcommand*{\miniframesoff}{\let\beamer@writeslidentry=\beamer@writeslidentry@miniframesoff} +\makeatother