Cheri-research/FAT-Allocator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added diagrams hugeTLB

Browse Source
This commit is contained in:
Akilan Selvacoumar
2025-02-11 13:02:42 +00:00
parent 35484d123a
commit c20c292d7d
6 changed files with 385 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/FAT-Pointer/FAT-Pointer.html
View File

@@ -3,7 +3,7 @@
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<!-- 2025-02-04 Tue 15:42 -->
<!-- 2025-02-10 Mon 17:17 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>&lrm;</title>
@@ -232,13 +232,13 @@
<h2>Table of Contents</h2>
<div id="text-table-of-contents" role="doc-toc">
<ul>
<li><a href="#orgc3dbff1">1. Fat-pointer Address Translations</a>
<li><a href="#org09fc007">1. Fat-pointer Address Translations</a>
<ul>
<li><a href="#org4cfe734">1.1. Encoding Ranges as Bounds to the Pointer</a></li>
<li><a href="#orga4aece2">1.2. Instrumenting Block-Based Allocators with Physically Contiguous Memory</a></li>
<li><a href="#org7e09c57">1.3. Implementation</a>
<li><a href="#orgc31066e">1.1. Encoding Ranges as Bounds to the Pointer</a></li>
<li><a href="#org3bc5d8c">1.2. Instrumenting Block-Based Allocators with Physically Contiguous Memory</a></li>
<li><a href="#org148206b">1.3. Implementation</a>
<ul>
<li><a href="#org61e32d1">1.3.1. kernel module</a></li>
<li><a href="#orge1c93e6">1.3.1. kernel module</a></li>
</ul>
</li>
</ul>
@@ -247,8 +247,8 @@
</div>
</div>
<div id="outline-container-orgc3dbff1" class="outline-2">
<h2 id="orgc3dbff1"><span class="section-number-2">1.</span> Fat-pointer Address Translations</h2>
<div id="outline-container-org09fc007" class="outline-2">
<h2 id="org09fc007"><span class="section-number-2">1.</span> Fat-pointer Address Translations</h2>
<div class="outline-text-2" id="text-1">
<p>
Fat-pointer Address Translations, combined with the capabilities of the CHERI (Capability Hardware Enhanced RISC Instructions)
@@ -265,14 +265,14 @@ control over memory regions.
</p>
<div id="org4b4d5eb" class="figure">
<p><img src="diagram/HighOverviewArchitecture24.png" alt="HighOverviewArchitecture24.png" />
<div id="org86ae870" class="figure">
<p><img src="diagram/HighOverviewArchitecture.drawio.png" alt="HighOverviewArchitecture.drawio.png" />
</p>
<p><span class="figure-number">Figure 1: </span>High overview architecture</p>
</div>
<p>
Figure \ref{fig:HighOverviewArchitecture} illustrates
Figure <a href="#org86ae870">1</a> illustrates
the methodology employed to leverage the CHERI
128-bit FAT-pointer scheme for facilitating
block-based memory management on physically
@@ -283,15 +283,15 @@ conventional mmap approach.
</p>
<p>
In figure \ref{fig:HighOverviewArchitecture}, the green-highlighted
In figure <a href="#org86ae870">1</a>, the green-highlighted
section marks the unused space between the 48th and 64th bits
within the FAT-pointer. This area of unused bits
presents an opportunity to store additional metadata,
potentially enhancing the capabilities of the
memory management system.
Here we explore how this additional
metadata storage could be used to further
optimize memory allocation.
Here we explore how using Huge pages
with CHERI bounds can reduce the
number of TLB entries required.
</p>
<p>
@@ -300,11 +300,11 @@ several key aspects:
</p>
</div>
<div id="outline-container-org4cfe734" class="outline-3">
<h3 id="org4cfe734"><span class="section-number-3">1.1.</span> Encoding Ranges as Bounds to the Pointer</h3>
<div id="outline-container-orgc31066e" class="outline-3">
<h3 id="orgc31066e"><span class="section-number-3">1.1.</span> Encoding Ranges as Bounds to the Pointer</h3>
<div class="outline-text-3" id="text-1-1">
<div id="orgc8ac9f0" class="figure">
<div id="orgd6304de" class="figure">
<p><img src="diagram/AllocationOverview24.png" alt="AllocationOverview24.png" />
</p>
<p><span class="figure-number">Figure 2: </span>Range of memory</p>
@@ -315,11 +315,11 @@ Integrating range bounds directly into FAT-pointers enables the architecture
to enforce memory access restrictions at the pointer level thus allowing
tracking of memory ranges on a pointer level. In this implementation, memory ranges are established using
bounds encoded within the FAT-pointer, adhering to the CHERI
128-bit bounds compression scheme\cite{woodruffcheri2019}.
128-bit bounds compression scheme\cite{woodruff_cheri_2019}.
</p>
<p>
Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single,
Figure <a href="#orgd6304de">2</a> 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.
This scenario simulates a block-based memory allocator operating within the confines of the huge page.
@@ -330,11 +330,11 @@ integrity and contiguity of the allocated blocks within the huge page.
</div>
</div>
<div id="outline-container-orga4aece2" class="outline-3">
<h3 id="orga4aece2"><span class="section-number-3">1.2.</span> Instrumenting Block-Based Allocators with Physically Contiguous Memory</h3>
<div id="outline-container-org3bc5d8c" class="outline-3">
<h3 id="org3bc5d8c"><span class="section-number-3">1.2.</span> Instrumenting Block-Based Allocators with Physically Contiguous Memory</h3>
<div class="outline-text-3" id="text-1-2">
<div id="org72e156a" class="figure">
<div id="org29ea26c" class="figure">
<p><img src="diagram/hugepages.drawio.png" alt="hugepages.drawio.png" />
</p>
<p><span class="figure-number">Figure 3: </span>Fat-pointer Address Translations using huge pages</p>
@@ -354,16 +354,22 @@ encoded within the FAT-pointer for efficient memory tracking and
access. This approach allows for precise and efficient memory management within the allocated huge page.
</p>
<ul class="org-ul">
<li>[ ]: Figure \ref{fig:HugePages} illustrates a use case of a huge page to ensure that the</li>
</ul>
<p>
Figure <a href="#org29ea26c">3</a> illustrates a use-case of huge pages where the green
line represents a sample access to read within a contigous
space of physical memory. The dotted lines represents the
bounds for that particular pointer access. Using bounds
stored on the pointer a block based pattern can be reprecated
on physically contigous memory.
</p>
</div>
</div>
<div id="outline-container-org7e09c57" class="outline-3">
<h3 id="org7e09c57"><span class="section-number-3">1.3.</span> Implementation</h3>
<div id="outline-container-org148206b" class="outline-3">
<h3 id="org148206b"><span class="section-number-3">1.3.</span> Implementation</h3>
<div class="outline-text-3" id="text-1-3">
<p>
#+BEGIN<sub>COMMENT</sub>
The software stack is based on CHERIBSD, selected because ARM officially supports Morello's performance
counters on this operating system. The setup includes a C program that
is linked to the prototype memory allocator or to various memory allocators being benchmarked. This linkage can occur in two ways: either as a shared object file during compile time
@@ -382,15 +388,21 @@ crucial for the high-performance needs of the application.
<li class="off"><code>[&#xa0;]</code> Requires rewrite</li>
</ul>
</div>
<div id="outline-container-org61e32d1" class="outline-4">
<h4 id="org61e32d1"><span class="section-number-4">1.3.1.</span> kernel module</h4>
<div id="outline-container-orge1c93e6" class="outline-4">
<h4 id="orge1c93e6"><span class="section-number-4">1.3.1.</span> kernel module</h4>
<div class="outline-text-4" id="text-1-3-1">
<p>
The custom mmap function is tailored to ensure physically contiguous memory is allocated. This allocation is a key component
of this system. The custom mmap function is interfaced to the contigmem driver, which has been modified from the DPDK\cite{bidpdk-based2016} library
of this system. The custom mmap function is interfaced to the contigmem driver, which has been modified from the DPDK library
. The contigmem driver is essential for managing large contiguous
memory blocks and is loaded during the system boot process. It reserves a huge page of arbitrary size, with the
size parameter set based on the requirements of the conducted experiments.
#+END<sub>COMMENT</sub>
</p>
<p>
\bibliographystyle{IEEEtran}
\bibliography{FAT-Pointer.bib}
</p>
</div>
</div>
@@ -399,7 +411,7 @@ size parameter set based on the requirements of the conducted experiments.
</div>
<div id="postamble" class="status">
<p class="author">Author: Akilan</p>
<p class="date">Created: 2025-02-04 Tue 15:42</p>
<p class="date">Created: 2025-02-10 Mon 17:17</p>
<p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
</body>

123
docs/FAT-Pointer/FAT-Pointer.org
View File

@@ -34,9 +34,9 @@ within the FAT-pointer. This area of unused bits
presents an opportunity to store additional metadata,
potentially enhancing the capabilities of the
memory management system.
Here we explore how this additional
metadata storage could be used to further
optimize memory allocation.
Here we explore how using Huge pages
with CHERI bounds can reduce the
number of TLB entries required.
The functionality of ranges encompasses
several key aspects:
@@ -63,7 +63,7 @@ integrity and contiguity of the allocated blocks within the huge page.
** Instrumenting Block-Based Allocators with Physically Contiguous Memory
#+CAPTION: Fat-pointer Address Translations using huge pages
#+NAME: fig:HugePages
[[file:diagram/hugepages.drawio.png]]
[[file:diagram/TLBAccess.drawio.png]]
hierarchical structures, to translate virtual addresses to physical addresses. This approach requires multiple entries to handle various
memory segments, leading to increased overhead and complexity
@@ -77,9 +77,15 @@ with managing numerous TLB entries and leverages the bounds
encoded within the FAT-pointer for efficient memory tracking and
access. This approach allows for precise and efficient memory management within the allocated huge page.
- [ ]: Figure [[fig:HugePages]] illustrates a use case of a huge page to ensure that the
Figure [[fig:HugePages]] illustrates a use-case of huge pages where the green
line represents a sample access to read within a contigous
space of physical memory. The dotted lines represents the
bounds for that particular pointer access. Using bounds
stored on the pointer a block based pattern can be reprecated
on physically contigous memory.
** Implementation
** Sample memory allocator Implementation
#+BEGIN_COMMENT
The software stack is based on CHERIBSD, selected because ARM officially supports Morello's performance
counters on this operating system. The setup includes a C program that
is linked to the prototype memory allocator or to various memory allocators being benchmarked. This linkage can occur in two ways: either as a shared object file during compile time
@@ -92,41 +98,32 @@ contigmem driver and the custom mmap function, the system achieves efficient mem
crucial for the high-performance needs of the application.
- [ ] Requires rewrite
*** kernel module
kernel module
The custom mmap function is tailored to ensure physically contiguous memory is allocated. This allocation is a key component
of this system. The custom mmap function is interfaced to the contigmem driver, which has been modified from the DPDK library
. The contigmem driver is essential for managing large contiguous
memory blocks and is loaded during the system boot process. It reserves a huge page of arbitrary size, with the
size parameter set based on the requirements of the conducted experiments.
#+END_COMMENT
This section presents a straightforward memory allocator designed and implemented based on the
principles outlined in our approach. 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
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,
where it can be integrated as an alternative to the mmap system call. This integration
ensures that memory allocations are physically contiguous, a critical requirement for
certain low-level operations and hardware interactions. By providing physically contiguous
memory blocks, this allocator can serve as a foundational layer for standard block-based allocators,
such as Jemalloc, enabling them to operate efficiently in environments where physical memory
contiguity is essential.
#+begin_export latex
\begin{algorithm}
\caption{Sample Memory Allocator Implementation}
\begin{algorithmic}[1]
\Function{malloc}{sz}
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
\State $\text{MallocCounter} \gets \text{MallocCounter} - sz$ \Comment{Update remaining memory}
\State $\text{ptrLink} \gets \&\text{ptr}[\text{MallocCounter}]$ \Comment{Calculate pointer address}
\State $\text{ptrLink} \gets \text{SET\_BOUNDS}(\text{ptrLink}, sz)$ \Comment{Set bounds for memory safety and to track the length of the pointer}
\State \Return $\text{ptrLink}$ \Comment{Return allocated memory pointer}
\EndFunction
\end{algorithmic}
\end{algorithm}
#+end_export
#+begin_export latex
\begin{algorithm}
\begin{algorithmic}[1]
\Function{free}{ptr}
\State $\text{len} \gets \text{GET\_LENGTH}(\text{ptr})$ \Comment{Get length of memory block from the defined bounds}
\State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
\EndFunction
\end{algorithmic}
\end{algorithm}
#+end_export
#+begin_export latex
\begin{algorithm}
\caption{Sample init alloc function to create a initial 1 GB huge page}
\begin{algorithmic}[1]
\Function{Init\_alloc}{}
\State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
@@ -138,7 +135,67 @@ size parameter set based on the requirements of the conducted experiments.
\end{algorithm}
#+end_export
Algorithm 1 describes the initialization of physically contiguous memory through the use of huge pages,
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
allocating a fixed block of 1 GB of physically contiguous memory. This decision is driven by the
architectural constraints of contemporary systems, particularly ARM-based CPUs, where 1 GB represents
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
with page table management and enhances memory access efficiency, which is critical for performance-sensitive
applications and kernel-level operations.
#+begin_export latex
\begin{algorithm}
\caption{Sample malloc implementation}
\begin{algorithmic}[1]
\Function{malloc}{sz}
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
\State $\text{MallocCounter} \gets \text{MallocCounter} - sz$ \Comment{Update remaining memory}
\State $\text{ptrLink} \gets \&\text{ptr}[\text{MallocCounter}]$ \Comment{Calculate pointer address}
\State $\text{ptrLink} \gets \text{SET\_BOUNDS}(\text{ptrLink}, sz)$ \Comment{Set bounds for memory safety and to track the length of the pointer}
\State \Return $\text{ptrLink}$ \Comment{Return allocated memory pointer}
\EndFunction
\end{algorithmic}
\end{algorithm}
#+end_export
When the malloc function 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-pointer—a 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
approach introduces a novel 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.
Furthermore, this design leverages shared huge page TLB (Translation Lookaside Buffer) entries to map
and track memory addresses. By encoding bounds directly into the address, the algorithm ensures that memory
accesses remain within the allocated region, thereby enhancing safety and reducing the risk of out-of-bounds
errors. This innovative use of FAT-pointers and shared TLB entries not only aligns with the principles of
efficient memory management but also demonstrates a practical application of huge pages in modern
architectures, offering a robust solution for physically contiguous memory allocation.
#+begin_export latex
\begin{algorithm}
\caption{Sample free implementation}
\begin{algorithmic}[1]
\Function{free}{ptr}
\State $\text{len} \gets \text{GET\_LENGTH}(\text{ptr})$ \Comment{Get length of memory block from the defined bounds}
\State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
\EndFunction
\end{algorithmic}
\end{algorithm}
#+end_export
The memory deallocation mechanism in the proposed allocator is facilitated by the FAT-pointer structure
introduced in the malloc algorithm. When the free function is invoked, it utilizes the metadata
embedded within the FAT-pointer to determine the range and size of the allocated memory region.
Specifically, the start and end addresses encoded in the FAT-pointer provide the necessary information
to identify the exact memory block to be deallocated. This allows the allocator to precisely unmapped
the corresponding memory region from the address space, ensuring efficient and accurate memory management.
By extracting the bounds and size directly from the FAT-pointer, the 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.
\bibliographystyle{IEEEtran}
\bibliography{FAT-Pointer.bib}

BIN
docs/FAT-Pointer/FAT-Pointer.pdf
View File

Binary file not shown.

152
docs/FAT-Pointer/FAT-Pointer.tex
View File

@@ -1,4 +1,4 @@
% Created 2025-02-10 Mon 13:11
% Created 2025-02-11 Tue 13:01
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
@@ -32,7 +32,7 @@
\section{Fat-pointer Address Translations}
\label{sec:org81645fa}
\label{sec:orgefab03e}
Fat-pointer Address Translations, combined with the capabilities of the CHERI (Capability Hardware Enhanced RISC Instructions)
architecture, introduce robust memory safety and security features by incorporating additional metadata
@@ -47,10 +47,10 @@ control over memory regions.
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{diagram/HighOverviewArchitecture.drawio.png}
\caption{\label{fig:org3f8fa4f}High overview architecture}
\caption{\label{fig:org26571f3}High overview architecture}
\end{figure}
Figure \ref{fig:org3f8fa4f} illustrates
Figure \ref{fig:org26571f3} illustrates
the methodology employed to leverage the CHERI
128-bit FAT-pointer scheme for facilitating
block-based memory management on physically
@@ -59,25 +59,25 @@ right side of the figure.
This technique contrasts with the
conventional mmap approach.
In figure \ref{fig:org3f8fa4f}, the green-highlighted
In figure \ref{fig:org26571f3}, the green-highlighted
section marks the unused space between the 48th and 64th bits
within the FAT-pointer. This area of unused bits
presents an opportunity to store additional metadata,
potentially enhancing the capabilities of the
memory management system.
Here we explore how this additional
metadata storage could be used to further
optimize memory allocation.
Here we explore how using Huge pages
with CHERI bounds can reduce the
number of TLB entries required.
The functionality of ranges encompasses
several key aspects:
\subsection{Encoding Ranges as Bounds to the Pointer}
\label{sec:orgd9309d3}
\label{sec:org2d3f5e4}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{diagram/AllocationOverview24.png}
\caption{\label{fig:org1826519}Range of memory}
\caption{\label{fig:orgd163080}Range of memory}
\end{figure}
Integrating range bounds directly into FAT-pointers enables the architecture
@@ -86,7 +86,7 @@ tracking of memory ranges on a pointer level. In this implementation, memory ran
bounds encoded within the FAT-pointer, adhering to the CHERI
128-bit bounds compression scheme\cite{woodruff_cheri_2019}.
Figure \ref{fig:org1826519} illustrates a straightforward use-case in which the dark pink line represents a single,
Figure \ref{fig:orgd163080} 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.
This scenario simulates a block-based memory allocator operating within the confines of the huge page.
@@ -95,11 +95,11 @@ management of the allocated memory regions. By using the FAT-pointer bounds, thi
integrity and contiguity of the allocated blocks within the huge page.
\subsection{Instrumenting Block-Based Allocators with Physically Contiguous Memory}
\label{sec:org33dc8de}
\label{sec:org52e34a5}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{diagram/hugepages.drawio.png}
\caption{\label{fig:org26a2828}Fat-pointer Address Translations using huge pages}
\includegraphics[width=.9\linewidth]{diagram/TLBAccess.drawio.png}
\caption{\label{fig:org5c993a2}Fat-pointer Address Translations using huge pages}
\end{figure}
hierarchical structures, to translate virtual addresses to physical addresses. This approach requires multiple entries to handle various
@@ -114,57 +114,32 @@ with managing numerous TLB entries and leverages the bounds
encoded within the FAT-pointer for efficient memory tracking and
access. This approach allows for precise and efficient memory management within the allocated huge page.
\begin{itemize}
\item\relax [ ]: Figure \ref{fig:org26a2828} illustrates a use case of a huge page to ensure that the
\end{itemize}
Figure \ref{fig:org5c993a2} illustrates a use-case of huge pages where the green
line represents a sample access to read within a contigous
space of physical memory. The dotted lines represents the
bounds for that particular pointer access. Using bounds
stored on the pointer a block based pattern can be reprecated
on physically contigous memory.
\subsection{Implementation}
\label{sec:org6da1716}
The software stack is based on CHERIBSD, selected because ARM officially supports Morello's performance
counters on this operating system. The setup includes a C program that
is linked to the prototype memory allocator or to various memory allocators being benchmarked. This linkage can occur in two ways: either as a shared object file during compile time
for larger allocators, or as a header file for smaller allocators, ensuring flexibility
in memory management.
\subsection{Sample memory allocator Implementation}
\label{sec:org61472fd}
This section presents a straightforward memory allocator designed and implemented based on the
principles outlined in our approach. 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
function deallocates the memory, returning it to the pool for future use.
This integration ensures that the memory allocation process is optimized for performance, leveraging the contiguity
of memory blocks and the capabilities provided by the CHERI architecture and the Morello platform. By using the
contigmem driver and the custom mmap function, the system achieves efficient memory allocation and tracking,
crucial for the high-performance needs of the application.
\begin{itemize}
\item[{$\square$}] Requires rewrite
\end{itemize}
\subsubsection{kernel module}
\label{sec:org37f0f43}
The custom mmap function is tailored to ensure physically contiguous memory is allocated. This allocation is a key component
of this system. The custom mmap function is interfaced to the contigmem driver, which has been modified from the DPDK library
. The contigmem driver is essential for managing large contiguous
memory blocks and is loaded during the system boot process. It reserves a huge page of arbitrary size, with the
size parameter set based on the requirements of the conducted experiments.
\begin{algorithm}
\caption{Sample Memory Allocator Implementation}
\begin{algorithmic}[1]
\Function{malloc}{sz}
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
\State $\text{MallocCounter} \gets \text{MallocCounter} - sz$ \Comment{Update remaining memory}
\State $\text{ptrLink} \gets \&\text{ptr}[\text{MallocCounter}]$ \Comment{Calculate pointer address}
\State $\text{ptrLink} \gets \text{SET\_BOUNDS}(\text{ptrLink}, sz)$ \Comment{Set bounds for memory safety and to track the length of the pointer}
\State \Return $\text{ptrLink}$ \Comment{Return allocated memory pointer}
\EndFunction
\end{algorithmic}
\end{algorithm}
\begin{algorithm}
\begin{algorithmic}[1]
\Function{free}{ptr}
\State $\text{len} \gets \text{GET\_LENGTH}(\text{ptr})$ \Comment{Get length of memory block from the defined bounds}
\State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
\EndFunction
\end{algorithmic}
\end{algorithm}
A notable feature of this malloc implementation is its compatibility with kernel modules,
where it can be integrated as an alternative to the mmap system call. This integration
ensures that memory allocations are physically contiguous, a critical requirement for
certain low-level operations and hardware interactions. By providing physically contiguous
memory blocks, this allocator can serve as a foundational layer for standard block-based allocators,
such as Jemalloc, enabling them to operate efficiently in environments where physical memory
contiguity is essential.
\begin{algorithm}
\caption{Sample init alloc function to create a initial 1 GB huge page}
\begin{algorithmic}[1]
\Function{Init\_alloc}{}
\State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
@@ -175,6 +150,61 @@ size parameter set based on the requirements of the conducted experiments.
\end{algorithmic}
\end{algorithm}
Algorithm 1 describes the initialization of physically contiguous memory through the use of huge pages,
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
allocating a fixed block of 1 GB of physically contiguous memory. This decision is driven by the
architectural constraints of contemporary systems, particularly ARM-based CPUs, where 1 GB represents
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
with page table management and enhances memory access efficiency, which is critical for performance-sensitive
applications and kernel-level operations.
\begin{algorithm}
\caption{Sample malloc implementation}
\begin{algorithmic}[1]
\Function{malloc}{sz}
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
\State $\text{MallocCounter} \gets \text{MallocCounter} - sz$ \Comment{Update remaining memory}
\State $\text{ptrLink} \gets \&\text{ptr}[\text{MallocCounter}]$ \Comment{Calculate pointer address}
\State $\text{ptrLink} \gets \text{SET\_BOUNDS}(\text{ptrLink}, sz)$ \Comment{Set bounds for memory safety and to track the length of the pointer}
\State \Return $\text{ptrLink}$ \Comment{Return allocated memory pointer}
\EndFunction
\end{algorithmic}
\end{algorithm}
When the malloc function 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-pointer—a 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
approach introduces a novel 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.
Furthermore, this design leverages shared huge page TLB (Translation Lookaside Buffer) entries to map
and track memory addresses. By encoding bounds directly into the address, the algorithm ensures that memory
accesses remain within the allocated region, thereby enhancing safety and reducing the risk of out-of-bounds
errors. This innovative use of FAT-pointers and shared TLB entries not only aligns with the principles of
efficient memory management but also demonstrates a practical application of huge pages in modern
architectures, offering a robust solution for physically contiguous memory allocation.
\begin{algorithm}
\caption{Sample free implementation}
\begin{algorithmic}[1]
\Function{free}{ptr}
\State $\text{len} \gets \text{GET\_LENGTH}(\text{ptr})$ \Comment{Get length of memory block from the defined bounds}
\State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
\EndFunction
\end{algorithmic}
\end{algorithm}
The memory deallocation mechanism in the proposed allocator is facilitated by the FAT-pointer structure
introduced in the malloc algorithm. When the free function is invoked, it utilizes the metadata
embedded within the FAT-pointer to determine the range and size of the allocated memory region.
Specifically, the start and end addresses encoded in the FAT-pointer provide the necessary information
to identify the exact memory block to be deallocated. This allows the allocator to precisely unmapped
the corresponding memory region from the address space, ensuring efficient and accurate memory management.
By extracting the bounds and size directly from the FAT-pointer, the 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.
\bibliographystyle{IEEEtran}
\bibliography{FAT-Pointer.bib}
\end{document}

BIN
docs/FAT-Pointer/diagram/TLBAccess.drawio.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 76 KiB

160
docs/FAT-Pointer/diagram/drawio/TLBAccess.drawio Normal file
View File

@@ -0,0 +1,160 @@
<mxfile host="app.diagrams.net" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36" version="26.0.11">
<diagram name="Page-1" id="G1hk7cXLOptppJQzhFXz">
<mxGraphModel dx="1194" dy="612" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
<root>
<mxCell id="0" />
<mxCell id="1" parent="0" />
<mxCell id="fsNtkcRwd-RCCKqtk2sz-1" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="130" y="490" width="80" height="570" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-2" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="280" y="220" width="480" height="110" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-3" value="48 bit virtual address" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="280" y="220" width="360" height="50" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-4" value="unused bits" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="640" y="220" width="120" height="50" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-5" value="Bounds&lt;div&gt;&lt;b&gt;Upper [11:3]&lt;/b&gt;&lt;/div&gt;&lt;div&gt;&lt;b&gt;Bottom [13:3&lt;/b&gt;]&lt;/div&gt;" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="280" y="270" width="210" height="60" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-6" value="object type" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="490" y="270" width="80" height="60" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-7" value="Permission" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="270" width="190" height="60" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-8" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="540" y="560" width="260" height="290" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-9" value="" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="610" width="200" height="140" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-10" value="Huge page entry" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="610" width="200" height="50" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-11" value="&lt;font style=&quot;font-size: 18px;&quot;&gt;Processor descirpton&lt;/font&gt;" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="540" y="790" width="260" height="60" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-12" value="&lt;h1 style=&quot;margin-top: 0px;&quot;&gt;&lt;span style=&quot;font-weight: normal;&quot;&gt;Pointer accessing memory region.&lt;/span&gt;&lt;/h1&gt;" style="text;html=1;whiteSpace=wrap;overflow=hidden;rounded=0;" parent="1" vertex="1">
<mxGeometry x="300" y="140" width="360" height="70" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-13" value="4k page entry" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="660" width="200" height="20" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-15" value="4k page entry" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="680" width="200" height="20" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-16" value="N page entry" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
<mxGeometry x="570" y="700" width="200" height="50" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-17" value="&lt;h1 style=&quot;margin-top: 0px;&quot;&gt;&lt;span style=&quot;font-weight: normal;&quot;&gt;L1 TLB&lt;/span&gt;&lt;/h1&gt;" style="text;html=1;whiteSpace=wrap;overflow=hidden;rounded=0;" parent="1" vertex="1">
<mxGeometry x="620" y="870" width="120" height="50" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-18" value="" style="endArrow=none;html=1;rounded=0;exitX=0;exitY=0.25;exitDx=0;exitDy=0;entryX=1;entryY=0.25;entryDx=0;entryDy=0;" parent="1" source="fsNtkcRwd-RCCKqtk2sz-1" target="fsNtkcRwd-RCCKqtk2sz-1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="430" y="580" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-19" value="" style="endArrow=none;html=1;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="130" y="820" as="sourcePoint" />
<mxPoint x="210" y="820" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-20" value="" style="endArrow=none;html=1;rounded=0;entryX=0;entryY=0.75;entryDx=0;entryDy=0;exitX=0;exitY=0.5;exitDx=0;exitDy=0;fillColor=#97D077;strokeColor=light-dark(#006600,#FFFFFF);" parent="1" source="fsNtkcRwd-RCCKqtk2sz-10" target="fsNtkcRwd-RCCKqtk2sz-3" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="480" y="660" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
<Array as="points">
<mxPoint x="470" y="630" />
<mxPoint x="470" y="430" />
<mxPoint x="210" y="430" />
<mxPoint x="210" y="258" />
</Array>
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-21" value="" style="endArrow=classic;html=1;rounded=0;entryX=1;entryY=0.25;entryDx=0;entryDy=0;exitX=0;exitY=0.5;exitDx=0;exitDy=0;" parent="1" source="fsNtkcRwd-RCCKqtk2sz-10" target="fsNtkcRwd-RCCKqtk2sz-1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="430" y="580" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-22" value="" style="endArrow=classic;html=1;rounded=0;entryX=0.964;entryY=0.584;entryDx=0;entryDy=0;entryPerimeter=0;" parent="1" target="fsNtkcRwd-RCCKqtk2sz-1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="570" y="640" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-23" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=2;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="110" y="690" as="sourcePoint" />
<mxPoint x="230" y="690" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-24" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=2;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="110" y="730" as="sourcePoint" />
<mxPoint x="220" y="730" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-25" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=2;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="210" y="690" as="sourcePoint" />
<mxPoint x="570" y="640" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-26" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=2;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="fsNtkcRwd-RCCKqtk2sz-10" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="210" y="730" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-27" value="" style="endArrow=none;html=1;rounded=0;strokeColor=light-dark(#006600,#FFFFFF);" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="210" y="710" as="sourcePoint" />
<mxPoint x="570" y="640" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-28" value="" style="endArrow=none;html=1;rounded=0;entryX=1.009;entryY=0.386;entryDx=0;entryDy=0;entryPerimeter=0;strokeColor=light-dark(#006600,#FFFFFF);" parent="1" target="fsNtkcRwd-RCCKqtk2sz-1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="130" y="710" as="sourcePoint" />
<mxPoint x="480" y="530" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-29" value="&lt;h1 style=&quot;margin-top: 0px;&quot;&gt;&lt;br&gt;&lt;/h1&gt;" style="text;html=1;whiteSpace=wrap;overflow=hidden;rounded=0;" parent="1" vertex="1">
<mxGeometry x="520" y="480" width="360" height="70" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-31" value="" style="endArrow=none;html=1;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="320" y="1030" as="sourcePoint" />
<mxPoint x="400" y="1030" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-32" value="Huge page" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1">
<mxGeometry x="310" y="990" width="60" height="30" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-35" value="" style="endArrow=none;dashed=1;html=1;dashPattern=1 3;strokeWidth=2;rounded=0;" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="320" y="1080" as="sourcePoint" />
<mxPoint x="400" y="1080" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-36" value="Bounds" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1">
<mxGeometry x="310" y="1050" width="60" height="30" as="geometry" />
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-41" value="" style="endArrow=none;html=1;rounded=0;strokeColor=light-dark(#97D077,#FFFFFF);" parent="1" edge="1">
<mxGeometry width="50" height="50" relative="1" as="geometry">
<mxPoint x="470" y="1030" as="sourcePoint" />
<mxPoint x="590" y="1030" as="targetPoint" />
</mxGeometry>
</mxCell>
<mxCell id="fsNtkcRwd-RCCKqtk2sz-42" value="Accessing memory region" style="text;html=1;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1">
<mxGeometry x="470" y="990" width="100" height="30" as="geometry" />
</mxCell>
</root>
</mxGraphModel>
</diagram>
</mxfile>