Context Navigation

-                      r4f3807d
+                      r847bb6f
 All of these benchmarks are run on two distinct hardware environment, an AMD and an INTEL machine.
 For all benchmarks, \texttt{taskset} is used to limit the experiment to 1 NUMA Node with no hyper threading.
+For all benchmarks, @taskset@ is used to limit the experiment to 1 NUMA Node with no hyper threading.
 If more \glspl{hthrd} are needed, then 1 NUMA Node with hyperthreading is used.
 If still more \glspl{hthrd} are needed then the experiment is limited to as few NUMA Nodes as needed.
 …
 \end{figure}
 The most basic evaluation of any ready queue is to evaluate the latency needed to push and pop one element from the ready-queue.
 Since these two operation also describe a \texttt{yield} operation, many systems use this as the most basic benchmark.
+Since these two operation also describe a @yield@ operation, many systems use this as the most basic benchmark.
 However, yielding can be treated as a special case, since it also carries the information that the number of the ready \glspl{at} will not change.
 Not all systems use this information, but those which do may appear to have better performance than they would for disconnected push/pop pairs.
 …
 This is to avoid the case where one of the \glspl{proc} runs out of work because of the variation on the number of ready \glspl{at} mentionned above.
 The actual benchmark is more complicated to handle termination, but that simply requires using a binary semphore or a channel instead of raw \texttt{park}/\texttt{unpark} and carefully picking the order of the \texttt{P} and \texttt{V} with respect to the loop condition.
+The actual benchmark is more complicated to handle termination, but that simply requires using a binary semphore or a channel instead of raw @park@/@unpark@ and carefully picking the order of the @P@ and @V@ with respect to the loop condition.
 Figure~\ref{fig:cycle:code} shows pseudo code for this benchmark.
 …
 \section{Yield}
 For completion, I also include the yield benchmark.
 This benchmark is much simpler than the cycle tests, it simply creates many \glspl{at} that call \texttt{yield}.
 As mentionned in the previous section, this benchmark may be less representative of usages that only make limited use of \texttt{yield}, due to potential shortcuts in the routine.
+This benchmark is much simpler than the cycle tests, it simply creates many \glspl{at} that call @yield@.
+As mentionned in the previous section, this benchmark may be less representative of usages that only make limited use of @yield@, due to potential shortcuts in the routine.
 Its only interesting variable is the number of \glspl{at} per \glspl{proc}, where ratios close to 1 means the ready queue(s) could be empty.
 This sometimes puts more strain on the idle sleep handling, compared to scenarios where there is clearly plenty of work to be done.
 …
 To achieve this the benchmark uses a fixed size array of semaphores.
 Each \gls{at} picks a random semaphore, \texttt{V}s it to unblock a \at waiting and then \texttt{P}s on the semaphore.
+Each \gls{at} picks a random semaphore, @V@s it to unblock a \at waiting and then @P@s on the semaphore.
 This creates a flow where \glspl{at} push each other out of the semaphores before being pushed out themselves.
 For this benchmark to work however, the number of \glspl{at} must be equal or greater to the number of semaphores plus the number of \glspl{proc}.
 Note that the nature of these semaphores mean the counter can go beyond 1, which could lead to calls to \texttt{P} not blocking.
+Note that the nature of these semaphores mean the counter can go beyond 1, which could lead to calls to @P@ not blocking.
 \todo{code, setup, results}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 847bb6f for doc/theses/thierry_delisle_PhD/thesis/text/eval_micro.tex

Legend:

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

Download in other formats: