added draft 1 of the FAT pointer section
This commit is contained in:
@@ -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-10 Mon 17:17 -->
|
||||
<!-- 2025-02-13 Thu 11:16 -->
|
||||
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>‎</title>
|
||||
@@ -232,23 +232,19 @@
|
||||
<h2>Table of Contents</h2>
|
||||
<div id="text-table-of-contents" role="doc-toc">
|
||||
<ul>
|
||||
<li><a href="#org09fc007">1. Fat-pointer Address Translations</a>
|
||||
<li><a href="#org2c44245">1. Fat-pointer Address Translations</a>
|
||||
<ul>
|
||||
<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="#orge1c93e6">1.3.1. kernel module</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#orge791f4e">1.1. Encoding Ranges as Bounds to the Pointer</a></li>
|
||||
<li><a href="#org4a57a8a">1.2. Instrumenting Block-Based Allocators with Physically Contiguous Memory</a></li>
|
||||
<li><a href="#org63c7417">1.3. Sample memory allocator Implementation</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org09fc007" class="outline-2">
|
||||
<h2 id="org09fc007"><span class="section-number-2">1.</span> Fat-pointer Address Translations</h2>
|
||||
<div id="outline-container-org2c44245" class="outline-2">
|
||||
<h2 id="org2c44245"><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,31 +261,25 @@ control over memory regions.
|
||||
</p>
|
||||
|
||||
|
||||
<div id="org86ae870" class="figure">
|
||||
<div id="org37578e7" 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 <a href="#org86ae870">1</a> illustrates
|
||||
Figure <a href="#org37578e7">1</a> illustrates
|
||||
the methodology employed to leverage the CHERI
|
||||
128-bit FAT-pointer scheme for facilitating
|
||||
block-based memory management on physically
|
||||
contiguous memory,which is depicted on the
|
||||
right side of the figure.
|
||||
This technique contrasts with the
|
||||
conventional mmap approach.
|
||||
conventional approach.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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 using Huge pages
|
||||
We explore how using Huge pages
|
||||
with CHERI bounds can reduce the
|
||||
number of TLB entries required.
|
||||
</p>
|
||||
@@ -300,11 +290,11 @@ several key aspects:
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<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 id="outline-container-orge791f4e" class="outline-3">
|
||||
<h3 id="orge791f4e"><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="orgd6304de" class="figure">
|
||||
<div id="orgc38e57b" class="figure">
|
||||
<p><img src="diagram/AllocationOverview24.png" alt="AllocationOverview24.png" />
|
||||
</p>
|
||||
<p><span class="figure-number">Figure 2: </span>Range of memory</p>
|
||||
@@ -319,7 +309,7 @@ bounds encoded within the FAT-pointer, adhering to the CHERI
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Figure <a href="#orgd6304de">2</a> illustrates a straightforward use-case in which the dark pink line represents a single,
|
||||
Figure <a href="#orgc38e57b">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,32 +320,41 @@ integrity and contiguity of the allocated blocks within the huge page.
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<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 id="outline-container-org4a57a8a" class="outline-3">
|
||||
<h3 id="org4a57a8a"><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="org29ea26c" class="figure">
|
||||
<p><img src="diagram/hugepages.drawio.png" alt="hugepages.drawio.png" />
|
||||
<div id="org2ea620c" class="figure">
|
||||
<p><img src="diagram/TLBAccess.drawio.png" alt="TLBAccess.drawio.png" />
|
||||
</p>
|
||||
<p><span class="figure-number">Figure 3: </span>Fat-pointer Address Translations using huge pages</p>
|
||||
</div>
|
||||
|
||||
<p>
|
||||
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
|
||||
in address translation. Conversely, the current approach stream-
|
||||
lines this process by using a single TLB entry to translate multiple
|
||||
addresses within a contiguous memory range. This reduces the
|
||||
number of required TLB entries, simplifying the translation process
|
||||
and improving efficiency. By consolidating address translations into
|
||||
a single TLB entry, this method minimizes the overhead associated
|
||||
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.
|
||||
Traditional address translation methods rely on hierarchical
|
||||
structures to map virtual addresses to physical addresses.
|
||||
This often requires multiple entries to handle different
|
||||
memory segments, which increases overhead and adds complexity
|
||||
to the translation process. In contrast, the current approach
|
||||
simplifies this by using a single TLB (Translation Lookaside Buffer)
|
||||
entry to translate multiple addresses within a contiguous memory
|
||||
range. This reduces the number of TLB entries needed, making the
|
||||
translation process more efficient and less complex.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Figure <a href="#org29ea26c">3</a> illustrates a use-case of huge pages where the green
|
||||
By consolidating address translations into a single TLB entry,
|
||||
this method cuts down on the overhead of managing many entries.
|
||||
It also takes advantage of the bounds encoded within fat-pointers
|
||||
to track and access memory more efficiently. This streamlined
|
||||
approach allows for precise and effective memory management,
|
||||
especially within large, contiguous memory regions like huge pages.
|
||||
Overall, it simplifies memory operations while improving performance
|
||||
and reduces TLB overhead by reducing TLB walks.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Figure <a href="#org2ea620c">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
|
||||
@@ -365,39 +364,68 @@ on physically contigous memory.
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org148206b" class="outline-3">
|
||||
<h3 id="org148206b"><span class="section-number-3">1.3.</span> Implementation</h3>
|
||||
<div id="outline-container-org63c7417" class="outline-3">
|
||||
<h3 id="org63c7417"><span class="section-number-3">1.3.</span> Sample memory allocator 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
|
||||
for larger allocators, or as a header file for smaller allocators, ensuring flexibility
|
||||
in memory management.
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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.
|
||||
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.
|
||||
</p>
|
||||
|
||||
<ul class="org-ul">
|
||||
<li class="off"><code>[ ]</code> Requires rewrite</li>
|
||||
</ul>
|
||||
</div>
|
||||
<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 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>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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 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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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 use of FAT-pointers and shared TLB entries not only aligns with the principles of
|
||||
efficient memory management but also demonstrates a practical usecase of huge pages in CHERI.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
@@ -408,10 +436,9 @@ size parameter set based on the requirements of the conducted experiments.
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div id="postamble" class="status">
|
||||
<p class="author">Author: Akilan</p>
|
||||
<p class="date">Created: 2025-02-10 Mon 17:17</p>
|
||||
<p class="date">Created: 2025-02-13 Thu 11:16</p>
|
||||
<p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
|
||||
</div>
|
||||
</body>
|
||||
|
||||
@@ -26,15 +26,9 @@ block-based memory management on physically
|
||||
contiguous memory,which is depicted on the
|
||||
right side of the figure.
|
||||
This technique contrasts with the
|
||||
conventional mmap approach.
|
||||
conventional approach.
|
||||
|
||||
In figure [[fig:HighOverviewArchitecture]], 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 using Huge pages
|
||||
We explore how using Huge pages
|
||||
with CHERI bounds can reduce the
|
||||
number of TLB entries required.
|
||||
|
||||
@@ -64,8 +58,8 @@ integrity and contiguity of the allocated blocks within the huge page.
|
||||
#+CAPTION: Fat-pointer Address Translations using huge pages
|
||||
#+NAME: fig:HugePages
|
||||
[[file:diagram/TLBAccess.drawio.png]]
|
||||
|
||||
hierarchical structures, to translate virtual addresses to physical addresses. This approach requires multiple entries to handle various
|
||||
#+BEGIN_COMMENT
|
||||
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
|
||||
in address translation. Conversely, the current approach stream-
|
||||
lines this process by using a single TLB entry to translate multiple
|
||||
@@ -76,6 +70,26 @@ a single TLB entry, this method minimizes the overhead associated
|
||||
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.
|
||||
#+END_COMMENT
|
||||
|
||||
Traditional address translation methods rely on hierarchical
|
||||
structures to map virtual addresses to physical addresses.
|
||||
This often requires multiple entries to handle different
|
||||
memory segments, which increases overhead and adds complexity
|
||||
to the translation process. In contrast, the current approach
|
||||
simplifies this by using a single TLB (Translation Lookaside Buffer)
|
||||
entry to translate multiple addresses within a contiguous memory
|
||||
range. This reduces the number of TLB entries needed, making the
|
||||
translation process more efficient and less complex.
|
||||
|
||||
By consolidating address translations into a single TLB entry,
|
||||
this method cuts down on the overhead of managing many entries.
|
||||
It also takes advantage of the bounds encoded within fat-pointers
|
||||
to track and access memory more efficiently. This streamlined
|
||||
approach allows for precise and effective memory management,
|
||||
especially within large, contiguous memory regions like huge pages.
|
||||
Overall, it simplifies memory operations while improving performance
|
||||
and reduces TLB overhead by reducing TLB walks.
|
||||
|
||||
Figure [[fig:HugePages]] illustrates a use-case of huge pages where the green
|
||||
line represents a sample access to read within a contigous
|
||||
@@ -124,6 +138,7 @@ contiguity is essential.
|
||||
#+begin_export latex
|
||||
\begin{algorithm}
|
||||
\caption{Sample init alloc function to create a initial 1 GB huge page}
|
||||
\label{alg:initAlloc}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{Init\_alloc}{}
|
||||
\State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
|
||||
@@ -135,7 +150,7 @@ contiguity is essential.
|
||||
\end{algorithm}
|
||||
#+end_export
|
||||
|
||||
Algorithm 1 describes the initialization of physically contiguous memory through the use of huge pages,
|
||||
Algorithm \ref{alg:initAlloc} 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
|
||||
@@ -146,6 +161,7 @@ applications and kernel-level operations.
|
||||
#+begin_export latex
|
||||
\begin{algorithm}
|
||||
\caption{Sample malloc implementation}
|
||||
\label{alg:malloc}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{malloc}{sz}
|
||||
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
|
||||
@@ -157,23 +173,23 @@ applications and kernel-level operations.
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
#+end_export
|
||||
When the malloc function is invoked, the algorithm employs an eager allocation strategy for physical memory.
|
||||
When the malloc function \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-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
|
||||
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.
|
||||
|
||||
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.
|
||||
errors. This use of FAT-pointers and shared TLB entries not only aligns with the principles of
|
||||
efficient memory management but also demonstrates a practical usecase of huge pages in CHERI.
|
||||
|
||||
#+begin_export latex
|
||||
\begin{algorithm}
|
||||
\caption{Sample free implementation}
|
||||
\label{alg:free}
|
||||
\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}
|
||||
@@ -183,7 +199,7 @@ architectures, offering a robust solution for physically contiguous memory alloc
|
||||
\end{algorithm}
|
||||
#+end_export
|
||||
|
||||
The memory deallocation mechanism in the proposed allocator is facilitated by the FAT-pointer structure
|
||||
The memory deallocation \ref{alg:free} 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
|
||||
@@ -196,6 +212,3 @@ This approach not only enhances performance but also reduces the risk of memory
|
||||
|
||||
\bibliographystyle{IEEEtran}
|
||||
\bibliography{FAT-Pointer.bib}
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
@@ -1,4 +1,4 @@
|
||||
% Created 2025-02-11 Tue 13:01
|
||||
% Created 2025-02-13 Thu 11:32
|
||||
% Intended LaTeX compiler: pdflatex
|
||||
\documentclass[11pt]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
@@ -32,7 +32,7 @@
|
||||
|
||||
|
||||
\section{Fat-pointer Address Translations}
|
||||
\label{sec:orgefab03e}
|
||||
\label{sec:org9194085}
|
||||
|
||||
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,25 +47,19 @@ control over memory regions.
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=.9\linewidth]{diagram/HighOverviewArchitecture.drawio.png}
|
||||
\caption{\label{fig:org26571f3}High overview architecture}
|
||||
\caption{\label{fig:orgcb94e61}High overview architecture}
|
||||
\end{figure}
|
||||
|
||||
Figure \ref{fig:org26571f3} illustrates
|
||||
Figure \ref{fig:orgcb94e61} illustrates
|
||||
the methodology employed to leverage the CHERI
|
||||
128-bit FAT-pointer scheme for facilitating
|
||||
block-based memory management on physically
|
||||
contiguous memory,which is depicted on the
|
||||
right side of the figure.
|
||||
This technique contrasts with the
|
||||
conventional mmap approach.
|
||||
conventional approach.
|
||||
|
||||
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 using Huge pages
|
||||
We explore how using Huge pages
|
||||
with CHERI bounds can reduce the
|
||||
number of TLB entries required.
|
||||
|
||||
@@ -73,11 +67,11 @@ The functionality of ranges encompasses
|
||||
several key aspects:
|
||||
|
||||
\subsection{Encoding Ranges as Bounds to the Pointer}
|
||||
\label{sec:org2d3f5e4}
|
||||
\label{sec:org312bc7d}
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=.9\linewidth]{diagram/AllocationOverview24.png}
|
||||
\caption{\label{fig:orgd163080}Range of memory}
|
||||
\caption{\label{fig:org18f47e9}Range of memory}
|
||||
\end{figure}
|
||||
|
||||
Integrating range bounds directly into FAT-pointers enables the architecture
|
||||
@@ -86,7 +80,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:orgd163080} illustrates a straightforward use-case in which the dark pink line represents a single,
|
||||
Figure \ref{fig:org18f47e9} 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,26 +89,33 @@ 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:org52e34a5}
|
||||
\label{sec:orgd7c897c}
|
||||
\begin{figure}[htbp]
|
||||
\centering
|
||||
\includegraphics[width=.9\linewidth]{diagram/TLBAccess.drawio.png}
|
||||
\caption{\label{fig:org5c993a2}Fat-pointer Address Translations using huge pages}
|
||||
\caption{\label{fig:org710cee0}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
|
||||
memory segments, leading to increased overhead and complexity
|
||||
in address translation. Conversely, the current approach stream-
|
||||
lines this process by using a single TLB entry to translate multiple
|
||||
addresses within a contiguous memory range. This reduces the
|
||||
number of required TLB entries, simplifying the translation process
|
||||
and improving efficiency. By consolidating address translations into
|
||||
a single TLB entry, this method minimizes the overhead associated
|
||||
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.
|
||||
Traditional address translation methods rely on hierarchical
|
||||
structures to map virtual addresses to physical addresses.
|
||||
This often requires multiple entries to handle different
|
||||
memory segments, which increases overhead and adds complexity
|
||||
to the translation process. In contrast, the current approach
|
||||
simplifies this by using a single TLB (Translation Lookaside Buffer)
|
||||
entry to translate multiple addresses within a contiguous memory
|
||||
range. This reduces the number of TLB entries needed, making the
|
||||
translation process more efficient and less complex.
|
||||
|
||||
Figure \ref{fig:org5c993a2} illustrates a use-case of huge pages where the green
|
||||
By consolidating address translations into a single TLB entry,
|
||||
this method cuts down on the overhead of managing many entries.
|
||||
It also takes advantage of the bounds encoded within fat-pointers
|
||||
to track and access memory more efficiently. This streamlined
|
||||
approach allows for precise and effective memory management,
|
||||
especially within large, contiguous memory regions like huge pages.
|
||||
Overall, it simplifies memory operations while improving performance
|
||||
and reduces TLB overhead by reducing TLB walks.
|
||||
|
||||
Figure \ref{fig:org710cee0} 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
|
||||
@@ -122,7 +123,7 @@ stored on the pointer a block based pattern can be reprecated
|
||||
on physically contigous memory.
|
||||
|
||||
\subsection{Sample memory allocator Implementation}
|
||||
\label{sec:org61472fd}
|
||||
\label{sec:org99d3fdd}
|
||||
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
|
||||
@@ -140,6 +141,7 @@ contiguity is essential.
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Sample init alloc function to create a initial 1 GB huge page}
|
||||
\label{alg:initAlloc}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{Init\_alloc}{}
|
||||
\State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
|
||||
@@ -150,7 +152,7 @@ contiguity is essential.
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
Algorithm 1 describes the initialization of physically contiguous memory through the use of huge pages,
|
||||
Algorithm \ref{alg:initAlloc} 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
|
||||
@@ -160,6 +162,7 @@ applications and kernel-level operations.
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Sample malloc implementation}
|
||||
\label{alg:malloc}
|
||||
\begin{algorithmic}[1]
|
||||
\Function{malloc}{sz}
|
||||
\State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
|
||||
@@ -170,22 +173,22 @@ applications and kernel-level operations.
|
||||
\EndFunction
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
When the malloc function is invoked, the algorithm employs an eager allocation strategy for physical memory.
|
||||
When the malloc function \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-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
|
||||
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.
|
||||
|
||||
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.
|
||||
errors. This use of FAT-pointers and shared TLB entries not only aligns with the principles of
|
||||
efficient memory management but also demonstrates a practical usecase of huge pages in CHERI.
|
||||
|
||||
\begin{algorithm}
|
||||
\caption{Sample free implementation}
|
||||
\label{alg:free}
|
||||
\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}
|
||||
@@ -194,7 +197,7 @@ architectures, offering a robust solution for physically contiguous memory alloc
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
The memory deallocation mechanism in the proposed allocator is facilitated by the FAT-pointer structure
|
||||
The memory deallocation \ref{alg:free} 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
|
||||
|
||||
BIN
docs/FAT-Pointer/diagram/.DS_Store
vendored
Normal file
BIN
docs/FAT-Pointer/diagram/.DS_Store
vendored
Normal file
Binary file not shown.
BIN
docs/FAT-Pointer/diagram/drawio/.DS_Store
vendored
Normal file
BIN
docs/FAT-Pointer/diagram/drawio/.DS_Store
vendored
Normal file
Binary file not shown.
Binary file not shown.
Reference in New Issue
Block a user