Huge pages, also known as large pages, allow for the allocation of memory in significantly larger chunks
compared to traditional small pages. By reducing the number of TLB entries needed to access a given amount
of memory, huge pages offer a potential avenue for optimising TLB utilisation by reducing the number
of memory, huge pages offer a potential avenue for optimising TLBs use by reducing the number
of entries needed to map large memory regions. This not only decreases the frequency of
TLB misses but also lowers the overhead associated with address translation. By minimising
these bottlenecks, huge pages can improve system performance in aspects such as speeding
@@ -357,15 +357,15 @@ Furthermore, it accelerates memory-intensive tasks by reducing the overhead asso
memory allocations. The contributions for the following paper are as follows:
\begin{itemize}
\item\textbf{FAT Addresses Translations}: Introduces FAT that include memory bounds, allowing
efficient tracking and management of physically contiguous memory regions (section ~\ref{sec:FatPointerTranslations}).
efficient tracking and management of physically contiguous memory regions (Section ~\ref{sec:FatPointerTranslations}).
\item\textbf{CHERI’s Capability-based Optimization}: Demonstrates how CHERI's architecture can be
used to optimize memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
(section ~\ref{sec:128bitCompressedBounds}).
(Section ~\ref{sec:128bitCompressedBounds}).
\item\textbf{Memory Allocation Algorithms}: Provides an algorithms for allocating, freeing
physically contiguous memory and integrating huge pages with CHERI's capability-based bounds for enhanced memory management
(section ~\ref{sec:MemoryAllocator}).
(Section ~\ref{sec:MemoryAllocator}).
\end{itemize}
Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s ability
@@ -417,7 +417,7 @@ physical start address. This straightforward method simplifies the translation
process for large memory areas but requires significant modifications to the
source code of applications.
\subsection{Range Memory Mapping (RMM)}
\subsection{Redundant Memory Mapping (RMM)}
Redundant Memory Mappings (RMM)~\cite{karakostas_redundant_2015} enhance memory management by introducing an additional range table
that pre-allocates contiguous physical pages for large memory allocations, creating ranges that
are both virtually and physically contiguous. This approach simplifies address translation
@@ -479,9 +479,9 @@ bounds encoding technique with an internal exponent mechanism that offers greate
\section{Fat Address Translations}
\label{sec:FatPointerTranslations}
Fat Address Translations(FAT) uses the CHERI architecture to
Fat Address Translations(FAT) uses the CHERI architecture to
bring about block based allocations in physically contiguous memory.
FAT leverages techniques like FlexPointer~\cite{chen_flexpointer_2023} and Range Memory Mapping (RMM)~\cite{karakostas_redundant_2015} to
FAT leverages techniques like FlexPointer~\cite{chen_flexpointer_2023} and RMM~\cite{karakostas_redundant_2015} to
reduce pressure on the TLB. A key component
in this implementation is the use of range addresses with CHERI CC~\cite{woodruff_cheri_2019}.
@@ -517,8 +517,8 @@ in this implementation is the use of range addresses with CHERI CC~\cite{woodruf
% \end{minipage}
\end{figure*}
Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (malloc()) and a proposed FAT method. The standard approach involves a C program interacting with a custom allocator, utilizing 48-bit
free virtual addresses and a TLB walk (L1, L2 and L3 cache) to achieve non-contiguous allocation in physical memory.
Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (\textit{malloc()}) and a proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit
virtual addresses and a TLB walker (L1, L2 and L3 cache) to achieve non-contiguous allocation in physical memory.
This typically results in more TLB entries and increased TLB misses increasing the reasoning to have more TLB walks.
In contrast, the FAT Address Translations method employs a custom allocator leveraging
physically contiguous memory by using CHERI to encode
@@ -547,16 +547,16 @@ bounds within the pointers and as shown in the figure \ref{fig:HighOverviewArchi
% Integrating range bounds directly into FAT-pointers enables the CHERI architecture
% to enforce memory access restrictions at the pointer level thus allowing
% tracking of memory ranges on a pointer level.
A memory range in FAT has 2 points to track memory in physical contiguous space which
is the top and bottom. These 2 points are 2 virtual addresses and the range consists of
addresses which lie within this and refers to addresses allocated by invoking malloc.
A memory range in FAT has two points to track memory in physical contiguous space which
is the top and bottom. These two points are two virtual addresses and the range consists of
addresses which lie within this and refers to addresses allocated by invoking \textit{malloc}.
In FAT memory ranges are established using
bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019}.
% as referred in section ~\ref{sec:128bitCompressedBounds}.
Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single,
large contiguous memory area, or huge page. Within this huge page, the orange and blue lines indicate
two separate memory allocations equivalent to invoking malloc twice to allocate memory in distinct regions.
two separate memory allocations equivalent to invoking \textit{malloc} twice to allocate memory in distinct regions.
This scenario simulates a block-based memory allocator operating within the confines of the huge page.
The allocations use the bounds encoded in the FAT, ensuring tracking of the allocated memory regions.
By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page.
@@ -589,7 +589,7 @@ allocated.
% eliminating the need for multiple TLB entries for each allocation.
Allocators like Jemalloc typically allocate objects under
512 bytes. When an object’s bounds cannot be precisely represented, padding is required to ensure
512 bytes. When an object's bounds cannot be precisely represented, padding is required to ensure
memory safety. However, it has been observed that Jemalloc rarely needs more than 6 bits to store the
exponent values within compressed bounds (as shown in~\cite{woodruff_cheri_2019}). This means that the default behavior of allocators such as Jemalloc, would allow precise
representation of bounds within CHERI CC.
@@ -658,10 +658,10 @@ on physically contigous memory.
\section{Memory allocator design}
\label{sec:MemoryAllocator}
This section presents a straightforward memory allocator designed and implemented based on the
principles outlined FAT (section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: InitAlloc,
malloc, and free. The InitAlloc function initializes the memory pool, setting up the necessary
data structures and metadata required for efficient memory management. The malloc function is
responsible for allocating a contiguous block of memory of a specified size, while the free
principles outlined FAT (Section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: \textit{InitAlloc},
\textit{malloc}, and \textit{free}. The \textit{InitAlloc} function initializes the memory pool, setting up the necessary
data structures and metadata required for efficient memory management. The \textit{malloc} function is
responsible for allocating a contiguous block of memory of a specified size, while the \textit{free}
function deallocates the memory, returning it to the pool for future use.
% A notable feature of this malloc implementation is its compatibility with kernel modules,
@@ -685,10 +685,10 @@ function deallocates the memory, returning it to the pool for future use.
\end{algorithmic}
\end{algorithm}
When the malloc function (Algorithm \ref{alg:malloc}) is invoked, the algorithm employs an eager allocation strategy for physical memory.
When the \textit{malloc} function (Algorithm \ref{alg:malloc}) is invoked, the algorithm employs an eager allocation strategy for physical memory.
This is achieved through the use of the SetBounds mechanism, which constructs a FAT specialized
pointer that encodes both the start and end addresses of the allocated memory region within the pointer
itself. The start and end addresses correspond to the size of the memory block requested by malloc. This
itself. The start and end addresses correspond to the size of the memory block requested by \textit{malloc}. This
approach introduces a method of memory tracking, where the bounds of the allocated region are
explicitly encoded in the address, enabling efficient monitoring and management of memory usage.
@@ -710,7 +710,7 @@ efficient memory management but also demonstrates a practical usecase of huge pa
\end{algorithm}
The memory deallocation (Algorithm \ref{alg:free}) mechanism in the proposed allocator is facilitated by the FAT structure
introduced in the malloc algorithm. When the free function is invoked, it uses the metadata
introduced in the \textit{malloc} algorithm. When the \textit{free} function is invoked, it uses the metadata
embedded within the FAT to determine the range and size of the allocated memory region.
Specifically, FAT encodes the start and end addresses of each allocation, providing the information needed to
identify the memory block to be deallocated. This enables the allocator to accurately unmap the corresponding
@@ -720,7 +720,7 @@ efficient memory management but also demonstrates a practical usecase of huge pa
% to identify the exact memory block to be deallocated. This allows the allocator to unmap
% the corresponding memory region from the address space.
By extracting the bounds and size directly from FAT, the free function eliminates the need
By extracting the bounds and size directly from FAT, the \textit{free} function eliminates the need
for additional metadata lookups or complex data structures.
% , streamlining the deallocation process.
% This approach not only enhances performance but also reduces the risk of memory leaks or fragmentation.
@@ -807,7 +807,7 @@ consideration for this evaluation.
Each C program was executed using two different memory allocators. The first was
the modified C allocator, imported as a header file. This approach was necessary
because the Benchmark ABI shared object file exhibited unexpected behavior,
failing to overwrite the C program at runtime with the intended malloc functions.
failing to overwrite the C program at runtime with the intended \textit{malloc} functions.
The second allocator was the standard OS memory allocator, which, in the case of
CHERIBSD, is Jemalloc.
@@ -862,7 +862,7 @@ the proposed changes.
The benchmarks~\cite{Benchmark} are classified into 2 classes:
\subsubsection{Micro benchmark}
We further elaborated on the two classes of benchmarks executed. Micro benchmarks (section~\ref{sec:Micro}).
We further elaborated on the two classes of benchmarks executed. Micro benchmarks (Section~\ref{sec:Micro}).
focused on particular allocation and deallocation patterns, such as sequential and
random memory accesses, to stress-test the allocator under controlled conditions.
Macro benchmarks involved real-world applications, offering insights into how
@@ -872,7 +872,7 @@ and varying execution contexts.
\begin{itemize}
\item\texttt{GLIBC}: The Glibc benchmark evaluates the performance of
malloc and free functions in single-threaded, multi-threaded,
\textit{malloc} and \textit{free} functions in single-threaded, multi-threaded,
and emulated multi-threading scenarios using various block sizes and
allocation patterns. It simulates real-world memory usage by partially
deallocating blocks in FIFO order and fully deallocating them in LIFO order.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
