202 lines
8.2 KiB
TeX
202 lines
8.2 KiB
TeX
% Created 2025-02-25 Tue 10:21
|
||
% Intended LaTeX compiler: pdflatex
|
||
\documentclass[11pt]{article}
|
||
\usepackage[utf8]{inputenc}
|
||
\usepackage[T1]{fontenc}
|
||
\usepackage{graphicx}
|
||
\usepackage{longtable}
|
||
\usepackage{wrapfig}
|
||
\usepackage{rotating}
|
||
\usepackage[normalem]{ulem}
|
||
\usepackage{amsmath}
|
||
\usepackage{amssymb}
|
||
\usepackage{capt-of}
|
||
\usepackage{hyperref}
|
||
\setcounter{secnumdepth}{0}
|
||
\author{Akilan}
|
||
\date{\today}
|
||
\title{}
|
||
\hypersetup{
|
||
pdfauthor={Akilan},
|
||
pdftitle={},
|
||
pdfkeywords={},
|
||
pdfsubject={},
|
||
pdfcreator={Emacs 29.4 (Org mode 9.6.15)},
|
||
pdflang={English}}
|
||
\begin{document}
|
||
|
||
\tableofcontents
|
||
|
||
|
||
\section*{Future work}
|
||
\label{sec:org69c56b9}
|
||
This documents is decision making to highlight
|
||
potential paths to take for this PhD.
|
||
We will initially talk about the current expirement
|
||
which is a FAT pointer based memory allocator
|
||
and will then expand into 2 potential paths:
|
||
|
||
\begin{itemize}
|
||
\item Cheri RISCV to prevent using the TLB.
|
||
\item Allocator evaluation based on stripping instruction
|
||
calls for larger allocators like Jemalloc.
|
||
\end{itemize}
|
||
|
||
|
||
\subsection*{1. Current expirement: FAT pointer based range addresses}
|
||
\label{sec:org72b7f3a}
|
||
\begin{center}
|
||
\includegraphics[width=.9\linewidth]{./HighOverviewArchitecture.drawio.png}
|
||
\label{orge7449fe}
|
||
\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
|
||
this approach we can use a single Huge page entry with bounds to ensure that
|
||
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}
|
||
\label{sec:org6aecc9c}
|
||
\begin{itemize}
|
||
\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:org679e3d0}
|
||
\begin{itemize}
|
||
\item ARM morello (Huge page size 1GB used)
|
||
\end{itemize}
|
||
|
||
\subsubsection*{Evaluation}
|
||
\label{sec:org00dd6a3}
|
||
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.
|
||
|
||
\subsubsection*{limitation}
|
||
\label{sec:orga9c8652}
|
||
\begin{itemize}
|
||
\item Using Huge page still requires a TLB entry which could be mitigated
|
||
(Refer to the FPGA work).
|
||
\item ARMv8 only supports using to virtual addresses so it's required to
|
||
bypass the TLB for address translation.
|
||
\end{itemize}
|
||
|
||
|
||
\subsection*{2. Cheri RISCV to prevent using the TLB}
|
||
\label{sec:orgff20030}
|
||
|
||
\begin{center}
|
||
\includegraphics[width=200px]{./MainOverview.png}
|
||
\label{orge10034a}
|
||
\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.
|
||
This is possible due to CHERI’s capability model, which supports
|
||
fine-grained memory protection and can encode bounds within pointers.
|
||
Utilizing Bounds in CHERI for Block-Based Allocation:
|
||
CHERI capabilities allow pointers to carry metadata about memory bounds,
|
||
providing hardware-enforced memory safety. By encoding the offset
|
||
and bounds within the pointer, the system can directly access memory
|
||
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:org684e10b}
|
||
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:orge8c4354}
|
||
|
||
\begin{center}
|
||
\includegraphics[width=.9\linewidth]{./memory_allocator.drawio.png}
|
||
\label{orgaff7895}
|
||
\end{center}
|
||
|
||
\subsubsection*{Box 1}
|
||
\label{sec:org19bde19}
|
||
The diagram above mentions 3 particular implementations. The first box which is the
|
||
standard THP(Transparent huge pages) utilised by modern allocators. THP initially
|
||
emphasises on doing smalled allocations and as the number of allocations grows
|
||
uses a technique which groups all smaller allocations together and when done
|
||
converts them into a large page of size 4mb in allocators such as jemalloc.
|
||
|
||
This approach does incur addtional operations such as grouping smaller allocations
|
||
chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
|
||
huge page is created the TLB misses are reduced.
|
||
|
||
\subsubsection*{Box 2}
|
||
\label{sec:org31e2b6f}
|
||
Box 2 which refers to our current implementation always pre-allocates huge pages
|
||
and untilises CHERI bounds to track each allocation inside the huge page. Allowing
|
||
a single entry with the combination of bounds to provide block based behavoir in
|
||
physically contigous memory while ensuring a pointer can only access a regoin
|
||
within it's defined bounds.
|
||
|
||
Another aspect to note is that the bounds can be of a dynamic size when defined. This is
|
||
in contrast to defining multiple page entries which need to be fixed sizes which means
|
||
they always incur multiple entries. In the current approach when the huge page size is
|
||
hit a new one is created. The limitaton of this is appraoch being we are limited to the
|
||
huge page set by the processor implementation (In our case the CHERI ARM v8.1).
|
||
|
||
\subsubsection*{Box 3}
|
||
\label{sec:org28e0813}
|
||
The 3rd box specifies an alternate appraoch by not using huge pages and required
|
||
memory is not required to be physically contigous. In this approach the pointer
|
||
stores all the metadata to the translation from virtual to physical addresses.
|
||
|
||
\subsubsection*{Building up from the work of Box 2 and Box 3}
|
||
\label{sec:org12eb9a0}
|
||
Box 2 and 3 from a high overview there is only minor difference which can be noted
|
||
which is 1 uses huge pages and other does not. Both approaches can strip down the
|
||
number intructions needed in modern allocators (Stripping away the need transitioning
|
||
from smaller to larger pages). This document is yet to give an exact breakdown.
|
||
|
||
As seen to the right of the diagram is a sample snippet of TC malloc from the paper
|
||
(Beyond malloc efficiency to fleet allocators). This whole span function would not
|
||
be required in our approach. The other benefit being easier get the approach by
|
||
getting mmap embedded inside the allocator.
|
||
|
||
\subsubsection*{Evaluation:}
|
||
\label{sec:org6f6e966}
|
||
\begin{itemize}
|
||
\item Amount of instructions that can be stripped away from the page aware
|
||
memory allocator.
|
||
\item Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
|
||
\item CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
|
||
reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
|
||
emitted vs regular ARMv8 clang program with the same allocator).
|
||
\end{itemize}
|
||
\end{document}
|