Lines Matching defs:of
65 The tracing framework in Barrelfish consists of three major components:
75 or -- with the help of Bfscope -- to a remote machine. On the remote machine
81 \chapter{Design and Implementation of the Tracing Framework in Barrelfish}
85 The tracing framework inside of Barrelfish existed already before this project
88 trace logs) we decided to change as little as possible on the interface of the
89 tracing framework. In the end the structure of the trace logs that are generated
93 In this section we want to look at the part of the tracing framework that is
95 order to create trace logs. One part of the tracing framework allows developers
100 integrates with the new version of the tracing framework. Bfscope is described
103 The typical lifecycle of using the tracing framework in Barrelfish looks like
109 \item[1.] Define the type of event that will trigger the start of tracing.
116 is to define the type of the event that will start the logging process. Having a
119 with rather small instrumentation of code (i.e.~number of events that actually
122 framework is essential. Having the flexibility of specifying a type of trace
123 event that will trigger the start and stop of the logging is an additional
125 developers to easily vary the portion of code they want to trace, without
126 changing the placement of a ``start'' and ``stop'' command all the time.
129 more interesting again: The old version of the tracing system allowed only for
139 of invoking the new flushing functionality.
145 \caption{A sequence diagram illustrating the flow of events when using the
153 \section{Definition of a Trace Event\label{sec:trace-event}}
155 Let us now define the structure of events that can be traced. Each event
157 that can hold 32 bits of arbitrary information. Both the Subsystem and the Event
175 As timestamps are stored as a 64 bit number, we need a total of 128 bits
177 layout of a single event can be seen in Figure \ref{fig:trace-event}.
191 \caption{Representation of a single trace event in memory in Barrelfish.}
199 As trace events are identified by the type of their Subsystem and Event (which
208 parameter of the trace events is not specified in Pleco, as this parameter is
216 inside of Barrelfish, but Aquarium will use the textual description to display
219 of the pleco file, the name of the event will be substituted for the textual
243 Parsing and interpreting of pleco files is part of the Barrelfish build process,
245 the Hake build process. An overview of how pleco files are integrated into the
255 file. This translation is taking place during the regular build process of
262 For the pleco file of Listing \ref{lst:pleco-file}, the header file shown in
276 into the tracing framework to work: enabling and disabling of Subsystems that
334 provided, and where it wasn't, the name of the Event has been used as a
336 This is no coincidence, as the usage of this JSON file is exactly to decode the
339 For the purpose of decoding the events, the old version of Aquarium had the
341 source code. This new way of defining Subsystems and Events in pleco files
343 are always consistent), and provides them with an automated way of having a
355 single instance of Barrelfish on multiple machines, and in this case the
361 between the two cores. Figure \ref{fig:ntp} illustrates the steps of the clock
383 \subsection{Enabling and Disabling of Events\label{sec:enabling-disabling}}
385 With the new version of Aquarium it is possible to filter out events in the
390 is the tracing of the network stack. The current way of achieving this filtering
397 removing the need of recompiling the entire tracing framework just because the
398 type of events that a developer is interested changed. With the hierarchical
399 structure of Subsystems and Events it was possible to implement this enabling
400 facility in a lightweight manner, as the number of Subsystems is quite small.
414 Bfscope will automatically flush the content of the trace buffers periodically.
415 This feature removes the need of having to call the flush procedure manually,
419 of your application executing its code -- this does not lead to a problem of
420 correctness, but it can heavily skew the flow of events in the Barrelfish as a
425 Bfscope is a Barrelfish program that enhances the functionality of the tracing
427 that the tracing in the Barrelfish code itself runs independently of Bfscope --
436 there are no messages exchanged as part of a protocol -- Bfscope simply sends
450 \chapter{Design and Implementation of the Analysis Tool Aquarium\label{sec:aquarium}}
452 \section{Design of Aquarium}
461 \item Support for different ways of input (e.g.~reading from file or
468 We decided to tackle the first three goals with the design of the architecture
469 of Aquarium, which we will discuss in Section \ref{sec:aquarium-architecture}.
471 led to the idea of making Aquarium scriptable, i.e.~to create an interface that
476 integrated into the visualization of Aquarium, alleviating the need to write
482 in the old version of Aquarium -- namely that it was written in C\# and only
484 of Aquarium in Java, so that cross platform portability will certainly not
502 The actual interpretation of the trace log data is done using an EventParser;
503 EventParser objects are independent of the type of data source. Note that the
505 been generated during the build process of Barrelfish, based on the pleco file.
508 the TracingSession object. Note that the flow of data is push based, i.e.~it is
511 source allows us to treat different types of data sources uniformly.
514 representation of the actual events in the trace log data, Activities are a new
515 concept that we introduced in Aquarium. An Activity is a sequence of Events,
519 event) might not be very interesting, but the duration of the entire
520 construction of the packet (an Activity) is what is actually very interesting.
522 of Activities must be flexibly definable. We achieved this by allowing
533 A class diagram illustrating the handling of Events and Activities can be seen
539 EventListUpdateHandler (an object being responsible to present a list of all
550 well. Due to a lack of time, we had to omit it in the end. Nevertheless from the
556 especially handy when considering the filtering functionality of Aquarium. In
564 care of it at all.
576 extend the functionality of Aquarium by adding custom scripts. The scripts are
605 Another possibility to extend Aquarium with the help of scripts is to write
610 wrapped in a ScriptActivityDecoder inside of Aquarium, which is -- as just
615 locking behaviour. For each activity, certain parameters such as the duration of
620 In this section we briefly want to look at how some of the already described
621 functionality looks in Aquarium with the help of some examples. Figure
623 Aquarium. The largest part of the GUI is used by the so called \emph{GraphView},
629 black circles on the bar of the core. The color of the bar shows which
637 Below the GraphView we see a list representation of the event data. With the
638 help of the \emph{sync} button (shown on the right top corner of the list), the
640 either of the two, the other view scrolls to that event. Using this
644 On the left part of the GUI we see the Filter menu. It allows to filter out
651 \caption{Screenshot of Aquarium displaying one trace log file.}
660 as well as in the Activity tab next to the Events list on the bottom of a
665 \caption{Screenshot of Aquarium displaying two script activities, one for
683 part of the trace log data, that is interesting to you.
687 \caption{Screenshot of Aquarium where core 0 is filtered out, as well as
700 \item Modify the source code of your programs as described in
703 part of the source code
730 // fire the event that triggers start of recording
735 // fire the event that triggers end of recording
755 ssh -L 6666:\textless IP of Barrelfish machine\textgreater:6666 \textless ssh-machine\textgreater
762 This chapter analyzes the performance of the tracing framework only inside of
767 inside of Barrelfish; This stems from the fact that if you do not want to
778 the entire runtime of Barrelfish, as the only used buffers are allocated at
779 startup of the system. The used buffer space currently consists of two main
790 works independently of the actual number of cores, the number of cores is
791 bounded assuming a limit of 64 cores. This leads to the following memory usage:
797 In addition to those buffers, a handful of pointers are stored, which in total
798 use less than 1 KB of memory. Therefore that the total amount of memory that the
805 We benchmarked the number of cycles that it takes to trace a single event in the
813 analyzing this part of the code. Since we added the functionality do dynamically
815 the execution of the code will be slower, compared to removing the statement
818 The results of the benchmark can be seen in Figure \ref{fig:boxplot}. The
819 benchmark shows that on the machine \texttt{nos5}, the average number of cycles
821 average number of cycles for a call, when the Subsystem is disabled is 9.950.
824 few outliers, but the vast majority of the events are closely around the
829 \caption{Boxplots showing the number of cycles that it takes to trace a
845 potentially affecting the outcome of the tracing heavily.