64 lines
4.6 KiB
TeX
64 lines
4.6 KiB
TeX
\section{Implementation}
|
|
|
|
In this section, the new components that were developed that enable the tracing of an arbitrary application in real-time, as well as the replay of those traces in DRAMSys, will be introduced.
|
|
|
|
At first, the DynamoRIO analyzer tool that produces the memory access traces and its place in the DrCacheSim-Framework will be explained.
|
|
Furthermore, the trace player for DRAMSys will acquire special focus as well as the mandatory cache model that is used to model the cache-filtering in a real system.
|
|
The last part will concentrate on the special architecture of new trace player and challenges the internal interconnection solves.
|
|
|
|
\subsection{Analysis tool}
|
|
|
|
As described in section TODO the dynamic binary instrumentation tool DynamoRIO will be used to trace the memory accesses while the target application is running.
|
|
Instead of writing a DynamoRIO client from the ground up, the DrCacheSim framework is used.
|
|
|
|
DrCacheSim is a DynamoRIO client that gathers memory and instruction access traces and forwards them to an analyzer tool.
|
|
It is a purely observational client, as it does not modify the behavior of the application.
|
|
|
|
Optionally, DrCacheSim converts the addresses of the memory accesses from virtual addresses into physical addresses, which is an important step for simulating a real memory system.
|
|
The physical address conversion only works on Linux and requires root privileges (or alternatively the CAP\_SYS\_ADMIN capability) for modern kernel versions.
|
|
The analyzer tool can either be running alongside with DrCacheSim (online) or operate on an internal trace format (offline).
|
|
As of writing this thesis, the offline tracing mode does not yet support the physical address conversation, so the online mode has to be used.
|
|
|
|
In case of the online tracing, DrCacheSim consists of two seperate processes:
|
|
\begin{itemize}
|
|
\item
|
|
A client-side which injects observational instructions into the application's code cache.
|
|
For every instruction or memory access, a data packet of the type \texttt{memref\_t} is generated.
|
|
|
|
\item
|
|
An analyzer-side which connects to the client and processes the \texttt{memref\_t} data packets.
|
|
The analyzer-side can contain many analysis tools that operate on those stream of records.
|
|
\end{itemize}
|
|
|
|
The \abbr{inter-process communication}{IPC} between the two parts is achieved through a \textit{named\ pipe}.
|
|
|
|
\begin{figure}
|
|
\input{img/thesis.tikzstyles}
|
|
\begin{center}
|
|
\tikzfig{img/drcachesim}
|
|
\caption{Structure of the DrCacheSim online tracing.}
|
|
\end{center}
|
|
\end{figure}
|
|
|
|
A \texttt{memref\_t} can either represent an instruction, a data reference or a metadata event such as a timestamp or a CPU identifier.
|
|
Besides of the type, the \abbr{process identifier}{PID} and \abbr{thread identifier}{TID} is included in every record to be able to associate them.
|
|
For an instruction marker, the size of the instruction as well as the virtual address of the instruction in the memory map is provided.
|
|
DrCacheSim stores the current mapping of all binary executables and shared libraries in a seperate file, so that it is possible to decode named instructions even after the application has exited.
|
|
For data references, the address and size of the desired access is provided as well the \abbr{program counter}{PC} from which it was initiated.
|
|
|
|
Analysis tools implement the \texttt{analysis\_tool\_t} interface as this enables the analyzer to forward a received record to multiple tools in a polymorphic manner.
|
|
In particular, the \texttt{process\_memref\_t()} method of a tool is called for incoming every record.
|
|
|
|
The newly developed DRAMTracer tool creates for every thread of the application a seperate trace file.
|
|
As it is not known how many threads an application will spawn, the tool will listen for records with new TIDs that it did not register yet.
|
|
For every data reference, a new entry in the corresponding trace file is made which contains the size and the address of the access, whether it was a read or write, and also a count of (computational) instructions that have been executed since the last reference.
|
|
This instruction count is used to approximate the delay between the memory accesses when the trace is replayed by DRAMSys as described in section TODO.
|
|
|
|
As of writing this thesis, there is no application binary interface for analysis tools defined in the DrCacheSim-Framework.
|
|
Therefore it is not possible to load the DRAMTracer tool as a shared library but rather it is required to modify the DynamoRIO source code to integrate the tool.
|
|
|
|
\subsection{DbiPlayer architecture}
|
|
|
|
This section covers the general architecture of the DbiPlayer, the new trace player for DRAMSys that replays the captured trace files.
|
|
|