FAT pointer section changes

docs/FAT-Pointer/FAT-Pointer.bbl

@@ -0,0 +1,33 @@
+% Generated by IEEEtran.bst, version: 1.14 (2015/08/26)
+\begin{thebibliography}{1}
+\providecommand{\url}[1]{#1}
+\csname url@samestyle\endcsname
+\providecommand{\newblock}{\relax}
+\providecommand{\bibinfo}[2]{#2}
+\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
+\providecommand{\BIBentryALTinterwordstretchfactor}{4}
+\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
+\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
+  \fontdimen4\font\relax}
+\providecommand{\BIBforeignlanguage}[2]{{%
+\expandafter\ifx\csname l@#1\endcsname\relax
+\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%
+\typeout{** loaded for the language `#1'. Using the pattern for}%
+\typeout{** the default language instead.}%
+\else
+\language=\csname l@#1\endcsname
+\fi
+#2}}
+\providecommand{\BIBdecl}{\relax}
+\BIBdecl
+
+\bibitem{woodruff_cheri_2019}
+\BIBentryALTinterwordspacing
+J.~Woodruff, A.~Joannou, H.~Xia, A.~Fox, R.~M. Norton, D.~Chisnall, B.~Davis,
+  K.~Gudka, N.~W. Filardo, A.~T. Markettos, M.~Roe, P.~G. Neumann, R.~N.~M.
+  Watson, and S.~W. Moore, ``{CHERI} concentrate: Practical compressed
+  capabilities,'' vol.~68, no.~10, pp. 1455--1469. [Online]. Available:
+  \url{https://ieeexplore.ieee.org/document/8703061/}
+\BIBentrySTDinterwordspacing
+
+\end{thebibliography}

docs/FAT-Pointer/FAT-Pointer.org

@@ -19,7 +19,7 @@ control over memory regions.
 #+NAME: fig:HighOverviewArchitecture
 [[file:diagram/HighOverviewArchitecture.drawio.png]]
 
-Figure \ref{fig:HighOverviewArchitecture} illustrates
+Figure [[fig:HighOverviewArchitecture]] illustrates
 the methodology employed to leverage the CHERI 
 128-bit FAT-pointer scheme for facilitating
 block-based memory management on physically
@@ -28,7 +28,7 @@ right side of the figure.
 This technique contrasts with the
 conventional mmap approach.
 
-In figure \ref{fig:HighOverviewArchitecture}, the green-highlighted
+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,
@@ -52,7 +52,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:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single, 
+Figure [[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. 
 This scenario simulates a block-based memory allocator operating within the confines of the huge page. 
@@ -77,7 +77,7 @@ 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 \ref{fig:HugePages} illustrates a use case of a huge page to ensure that the
+- [ ]: Figure [[fig:HugePages]] illustrates a use case of a huge page to ensure that the
 
 ** Implementation
 The software stack is based on CHERIBSD, selected because ARM officially supports Morello's performance 
@@ -99,7 +99,46 @@ of this system. The custom mmap function is interfaced to the contigmem driver,
 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_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}
+\begin{algorithmic}[1]
+\Function{Init\_alloc}{}
+    \State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
+    \State $\text{fd} \gets \text{CREATE\_LARGE\_PAGE\_MEMORY}(\text{sz})$ \Comment{Create shared memory}
+    \State $\text{ptr} \gets \text{MAP\_MEMORY}(\text{sz})$ \Comment{Map memory region}
+    \State $\text{MallocCounter} \gets \text{sz}$ \Comment{Initialize memory counter}
+\EndFunction
+\end{algorithmic}
+\end{algorithm}
+#+end_export
+
 \bibliographystyle{IEEEtran}
-\bibliography{FATPointer.bib}
+\bibliography{FAT-Pointer.bib}
 
 

docs/FAT-Pointer/FAT-Pointer.tex

@@ -1,4 +1,4 @@
-% Created 2025-02-05 Wed 17:11
+% Created 2025-02-10 Mon 13:11
 % Intended LaTeX compiler: pdflatex
 \documentclass[11pt]{article}
 \usepackage[utf8]{inputenc}
@@ -32,7 +32,7 @@
 
 
 \section{Fat-pointer Address Translations}
-\label{sec:org98b9cf6}
+\label{sec:org81645fa}
 
 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:orgf77b5d6}High overview architecture}
+\caption{\label{fig:org3f8fa4f}High overview architecture}
 \end{figure}
 
-Figure \ref{fig:HighOverviewArchitecture} illustrates
+Figure \ref{fig:org3f8fa4f} illustrates
 the methodology employed to leverage the CHERI 
 128-bit FAT-pointer scheme for facilitating
 block-based memory management on physically
@@ -59,7 +59,7 @@ right side of the figure.
 This technique contrasts with the
 conventional mmap approach.
 
-In figure \ref{fig:HighOverviewArchitecture}, the green-highlighted
+In figure \ref{fig:org3f8fa4f}, 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,
@@ -73,11 +73,11 @@ The functionality of ranges encompasses
 several key aspects:
 
 \subsection{Encoding Ranges as Bounds to the Pointer}
-\label{sec:org333c91d}
+\label{sec:orgd9309d3}
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.9\linewidth]{diagram/AllocationOverview24.png}
-\caption{\label{fig:org7770b41}Range of memory}
+\caption{\label{fig:org1826519}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:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single, 
+Figure \ref{fig:org1826519} 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:orgc5f7075}
+\label{sec:org33dc8de}
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=.9\linewidth]{diagram/hugepages.drawio.png}
-\caption{\label{fig:org0063361}Fat-pointer Address Translations using huge pages}
+\caption{\label{fig:org26a2828}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
@@ -115,11 +115,11 @@ 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:HugePages} illustrates a use case of a huge page to ensure that the
+\item\relax [ ]: Figure \ref{fig:org26a2828} illustrates a use case of a huge page to ensure that the
 \end{itemize}
 
 \subsection{Implementation}
-\label{sec:orgea27970}
+\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 
@@ -135,13 +135,46 @@ crucial for the high-performance needs of the application.
 \item[{$\square$}] Requires rewrite
 \end{itemize}
 \subsubsection{kernel module}
-\label{sec:org1d0969e}
+\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}
+
+\begin{algorithm}
+\begin{algorithmic}[1]
+\Function{Init\_alloc}{}
+    \State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
+    \State $\text{fd} \gets \text{CREATE\_LARGE\_PAGE\_MEMORY}(\text{sz})$ \Comment{Create shared memory}
+    \State $\text{ptr} \gets \text{MAP\_MEMORY}(\text{sz})$ \Comment{Map memory region}
+    \State $\text{MallocCounter} \gets \text{sz}$ \Comment{Initialize memory counter}
+\EndFunction
+\end{algorithmic}
+\end{algorithm}
+
 \bibliographystyle{IEEEtran}
-\bibliography{FATPointer.bib}
+\bibliography{FAT-Pointer.bib}
 \end{document}

docs/LiteratureReview/LiteratureReview.tex

@@ -1,4 +1,4 @@
-% Created 2025-01-20 Mon 15:17
+% Created 2025-02-04 Tue 16:03
 % Intended LaTeX compiler: pdflatex
 \documentclass[11pt]{article}
 \usepackage[utf8]{inputenc}
@@ -27,10 +27,10 @@
 \tableofcontents
 
 \section{Literature Review}
-\label{sec:org3735e9d}
+\label{sec:org0e192da}
 
 \subsection{Huge Pages}
-\label{sec:orgac849a1}
+\label{sec:org880f002}
 Increasing TLB reach can be achieved by using larger page sizes, such as huge pages\cite{panwar_hawkeye_2019}, which are common in modern computer systems. 
 The x86-64 architecture supports huge pages of 2 MB and 1 GB, backed by OS mechanisms like Transparent Huge Pages (THP)\cite{THP} 
 and HugeTLBFS in Linux. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues. 
@@ -45,7 +45,7 @@ TLB coverage. However, this approach requires all memory traffic to be translate
 resulting in additional latency for memory accesses.
 
 \subsection{Direct Segment}
-\label{sec:org4ee3203}
+\label{sec:orgea5d98c}
 Early processors often used segments to manage virtual memory, where a segment\cite{DirectSegment} essentially mapped contiguous 
 virtual memory to contiguous physical memory. Unlike pages, which are relatively small, segments can be much 
 larger, offering the potential for more efficient memory management in certain scenarios. 
@@ -62,7 +62,7 @@ process for large memory areas but requires significant modifications to the
 source code of applications.
 
 \subsection{Range Memory Mapping (RMM)}
-\label{sec:orgd19b3b4}
+\label{sec:org5468886}
 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 
@@ -87,7 +87,7 @@ that most last level TLB misses are handled efficiently by range mapping,
 reducing the need for costly page table walks.
 
 \subsection{CHERI}
-\label{sec:org2a48228}
+\label{sec:orgbf2eaac}
 CHERI (Capability Hardware Enhanced RISC Instructions) extends conventional processor
 Instruction-Set Architectures (ISAs) with architectural capabilities to enable fine-grained
 memory protection and highly scalable software compartmentalization. CHERI is a hybrid 

docs/evaluation/evaluation.org

@@ -218,7 +218,7 @@ clock run times.
 #+END_COMMENT
 
 
-The graph[[[fig:bargraph]]] highlights the performance comparison between the modified memory allocator and 
+The graph[[fig:bargraph]] highlights the performance comparison between the modified memory allocator and 
 Jemalloc, the default memory allocator. The FAT pointer memory allocator, specifically optimized 
 for use with huge pages, demonstrates a clear advantage in scenarios where memory allocation 
 patterns benefit from its design. The results align with expectations, showcasing the impact 

docs/tasks/tasks.org

@@ -1,18 +1,31 @@
 * Tasks
-- [ ] Run 2 macro benchmarks
-   - [ ] Nqueens
+** Benchmarks related
+- [x] Run 2 macro benchmarks
+   - [x] Nqueens
       - [x] Executes on the regular allocator
 	    on the Morello.
       - [x] Executes on the Huge page aware
 	    allocator.
-      - [ ] Log results.
-   - [ ] Larison
+      - [x] Log results.
+   - [x] Larison
       - [x] Execute on the regular allocator
       - [x] Execute on the Morello
-- [ ] Log results and draw graphs
+- [x] Log results and draw graphs
 - [ ] Show in meeting notes
 
-(Attempt to compelte by 20:00)
+** Memory allocator design related
+- [ ] (2 hours) Run through source code Mesh allocator.
+        - [ ] Document findings (Fragmentation related) 
+- [ ] (1 hour) Porting effort to Morello.
+
+** Plan FAT pointer section changes (2 hours)
+- [ ] Describe high overview structure. 
+- [ ] Changes to be done.
+
+
+
+
+
 
 * Meeting notes template
 - Chapters sent for review.