diff --git a/docs/FutureTasks/HighOverviewArchitecture.drawio.png b/docs/FutureTasks/HighOverviewArchitecture.drawio.png new file mode 100644 index 0000000..9baa72d Binary files /dev/null and b/docs/FutureTasks/HighOverviewArchitecture.drawio.png differ diff --git a/docs/FutureTasks/MainOverview.png b/docs/FutureTasks/MainOverview.png new file mode 100644 index 0000000..94eca74 Binary files /dev/null and b/docs/FutureTasks/MainOverview.png differ diff --git a/docs/FutureTasks/docs.org b/docs/FutureTasks/docs.org index 17d8650..e56cdb3 100644 --- a/docs/FutureTasks/docs.org +++ b/docs/FutureTasks/docs.org @@ -1,3 +1,5 @@ +#+options: num:0 + * Future work This documents is decision making to highlight potential paths to take for this PhD. @@ -10,9 +12,9 @@ and will then expand into 2 potential paths: calls for larger allocators like Jemalloc. -** Current expirement: FAT pointer based range addresses - -- TODO add diagram +** 1. Current expirement: FAT pointer based range addresses +#+NAME: fig:FPBRA +[[./HighOverviewArchitecture.drawio.png]] The objective of this expirement was to ensure we can use the CHERI bounds as tracking mechanism of allocations instead of using multiple TLB entries. Using @@ -21,14 +23,37 @@ the bounds (Which is the top and base address) can be extracted from the pointer using the Cheri compressed bounds mechanism. We implemented a simple allocator which uses this technique with a basic malloc and free. -*** Objectives (Todo steal research questions from the paper) -- Reduce the number of TLB walks (Reducing each transaltion to 2 CPU CYCLES with huge pages). -- Using a block based style allocations inside huge pages. - +*** Objectives +- How does the utilization of bounds for tracking memory + allocations, in addition to security purposes, affect + the run times and Translation Lookaside Buffer (TLB) + miss rates in modern computing systems ? + +- How does the implementation of bounds for seeking through + physically contiguous memory influence the complexity and + efficiency of standard memory allocators, particularly + those with advanced features such as transparent huge pages, + and what are the implications for system performance in terms + of execution speed, memory access latency, and resource + utilization? + *** Hardware - ARM morello (Huge page size 1GB used) -*** Evaluation (Steal evaluation from the paper) +*** Evaluation + We conducted tests of the FAT Pointer-based range addresses against Jemalloc, + the default memory allocator for CHERIBSD, to assess the + performance improvements enabled by a CHERI-based huge page-aware + alocator. Specifically, we evaluated the reduction in TLB misses + and its impact on overall performance metrics, such as wall clock runtime. + To comprehensively analyze the proposed allocator, +we categorized benchmarks into two classes which are micro and +macro benchmarks. Micro benchmarks comprise smaller C programs +designed to target specific allocator patterns, enabling us +to evaluate detailed aspects of the allocator’s behavior. +Macro benchmarks, on the other hand, encompass larger, +realworld C programs, allowing us to assess the allocator’s +performance in more practical, real-world scenarios. *** limitation - Using Huge page still requires a TLB entry which could be mitigated @@ -37,7 +62,12 @@ allocator which uses this technique with a basic malloc and free. bypass the TLB for address translation. -** Cheri RISCV to prevent using the TLB +** 2. Cheri RISCV to prevent using the TLB + +#+attr_latex: :width 200px +#+NAME: fig:RFPBRA +[[./MainOverview.png]] + In the current ARM Morello setup, address translations rely on the TLB. The future approach on RISC-V Tooba involves storing the offset directly within the pointer. @@ -59,4 +89,7 @@ physical address from the capability information. This modification reduces the dependency on the TLB, decreasing latency. and improving performance, especially for frequent memory operations. -** Allocator evaluation based on stripping instruction calls for larger allocators +** 3. Allocator evaluation based on stripping instruction calls for larger allocators + +#+NAME: fig:MEMALLOC +[[./memory_allocator.drawio.png]] diff --git a/docs/FutureTasks/docs.pdf b/docs/FutureTasks/docs.pdf index 2b96ffc..bf0eb78 100644 Binary files a/docs/FutureTasks/docs.pdf and b/docs/FutureTasks/docs.pdf differ diff --git a/docs/FutureTasks/docs.tex b/docs/FutureTasks/docs.tex index 5f6b292..af245f7 100644 --- a/docs/FutureTasks/docs.tex +++ b/docs/FutureTasks/docs.tex @@ -1,4 +1,4 @@ -% Created 2025-02-22 Sat 16:07 +% Created 2025-02-24 Mon 15:33 % Intended LaTeX compiler: pdflatex \documentclass[11pt]{article} \usepackage[utf8]{inputenc} @@ -12,6 +12,7 @@ \usepackage{amssymb} \usepackage{capt-of} \usepackage{hyperref} +\setcounter{secnumdepth}{0} \author{Akilan} \date{\today} \title{} @@ -26,8 +27,9 @@ \tableofcontents -\section{Future work} -\label{sec:org9893feb} + +\section*{Future work} +\label{sec:org4e66dc8} This documents is decision making to highlight potential paths to take for this PhD. We will initially talk about the current expirement @@ -41,12 +43,12 @@ calls for larger allocators like Jemalloc. \end{itemize} -\subsection{Current expirement: FAT pointer based range addresses} -\label{sec:org538d2a3} - -\begin{itemize} -\item TODO add diagram -\end{itemize} +\subsection*{1. Current expirement: FAT pointer based range addresses} +\label{sec:orgb9d89c6} +\begin{center} +\includegraphics[width=.9\linewidth]{./HighOverviewArchitecture.drawio.png} +\label{orgb8f5fe3} +\end{center} The objective of this expirement was to ensure we can use the CHERI bounds as tracking mechanism of allocations instead of using multiple TLB entries. Using @@ -55,24 +57,47 @@ the bounds (Which is the top and base address) can be extracted from the pointer using the Cheri compressed bounds mechanism. We implemented a simple allocator which uses this technique with a basic malloc and free. -\subsubsection{Objectives (Todo steal research questions from the paper)} -\label{sec:org4ffe05f} +\subsubsection*{Objectives} +\label{sec:org0ebfce1} \begin{itemize} -\item Reduce the number of TLB walks (Reducing each transaltion to 2 CPU CYCLES with huge pages). -\item Using a block based style allocations inside huge pages. +\item How does the utilization of bounds for tracking memory +allocations, in addition to security purposes, affect +the run times and Translation Lookaside Buffer (TLB) +miss rates in modern computing systems ? + +\item How does the implementation of bounds for seeking through +physically contiguous memory influence the complexity and +efficiency of standard memory allocators, particularly +those with advanced features such as transparent huge pages, +and what are the implications for system performance in terms +of execution speed, memory access latency, and resource +utilization? \end{itemize} -\subsubsection{Hardware} -\label{sec:orgee1de56} +\subsubsection*{Hardware} +\label{sec:org5c66697} \begin{itemize} \item ARM morello (Huge page size 1GB used) \end{itemize} -\subsubsection{Evaluation (Steal evaluation from the paper)} -\label{sec:orgc7e36f5} +\subsubsection*{Evaluation} +\label{sec:orga66e547} + We conducted tests of the FAT Pointer-based range addresses against Jemalloc, + the default memory allocator for CHERIBSD, to assess the + performance improvements enabled by a CHERI-based huge page-aware + alocator. Specifically, we evaluated the reduction in TLB misses + and its impact on overall performance metrics, such as wall clock runtime. + To comprehensively analyze the proposed allocator, +we categorized benchmarks into two classes which are micro and +macro benchmarks. Micro benchmarks comprise smaller C programs +designed to target specific al- locator patterns, enabling us +to evaluate detailed aspects of the allocator’s behavior. +Macro benchmarks, on the other hand, encompass larger, +realworld C programs, allowing us to assess the allocator’s +performance in more practical, real-world scenarios. -\subsubsection{limitation} -\label{sec:org1f89017} +\subsubsection*{limitation} +\label{sec:org1aa7249} \begin{itemize} \item Using Huge page still requires a TLB entry which could be mitigated (Refer to the FPGA work). @@ -81,8 +106,14 @@ bypass the TLB for address translation. \end{itemize} -\subsection{Cheri RISCV to prevent using the TLB} -\label{sec:org81619f5} +\subsection*{2. Cheri RISCV to prevent using the TLB} +\label{sec:orgcde003a} + +\begin{center} +\includegraphics[width=200px]{./MainOverview.png} +\label{orgfab8f7b} +\end{center} + In the current ARM Morello setup, address translations rely on the TLB. The future approach on RISC-V Tooba involves storing the offset directly within the pointer. @@ -96,12 +127,20 @@ without needing intermediate translations via the TLB. This enables the implementation of a block-based allocator that can efficiently manage memory allocations and deallocations within defined bounds. Bypassing the TLB in RISC-V Tooba. -\subsubsection{Hardware modifications} -\label{sec:orgc0b3d36} +\subsubsection*{Hardware modifications} +\label{sec:org4c2f4f3} The Bluespec design of the RISC-V processor will be modified to allow certain memory operations to bypass the TLB. This means that when a pointer with encoded offset and bounds is used, the system can directly compute the physical address from the capability information. This modification reduces the dependency on the TLB, decreasing latency. and improving performance, especially for frequent memory operations. + +\subsection*{3. Allocator evaluation based on stripping instruction calls for larger allocators} +\label{sec:org08c9e01} + +\begin{center} +\includegraphics[width=.9\linewidth]{./memory_allocator.drawio.png} +\label{orge9efcc8} +\end{center} \end{document} diff --git a/docs/FutureTasks/memory_allocator.drawio b/docs/FutureTasks/memory_allocator.drawio new file mode 100644 index 0000000..16d8619 --- /dev/null +++ b/docs/FutureTasks/memory_allocator.drawio @@ -0,0 +1,455 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/FutureTasks/memory_allocator.drawio.png b/docs/FutureTasks/memory_allocator.drawio.png new file mode 100644 index 0000000..bff075a Binary files /dev/null and b/docs/FutureTasks/memory_allocator.drawio.png differ