added stable version of the document

This commit is contained in:
2025-02-26 15:37:50 +00:00
parent 95791bf121
commit c773ec12bd
5 changed files with 421 additions and 77 deletions

View File

@@ -0,0 +1,63 @@
@article{woodruff_cheri_2019,
title = {{CHERI} {Concentrate}: {Practical} {Compressed} {Capabilities}},
volume = {68},
copyright = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html},
issn = {0018-9340, 1557-9956, 2326-3814},
shorttitle = {{CHERI} {Concentrate}},
url = {https://ieeexplore.ieee.org/document/8703061/},
doi = {10.1109/TC.2019.2914037},
abstract = {We present CHERI Concentrate, a new fat-pointer compression scheme applied to CHERI, the most developed capability-pointer system at present. Capability fat pointers are a primary candidate to enforce fine-grained and non-bypassable security properties in future computer systems, although increased pointer size can severely affect performance. Thus, several proposals for capability compression have been suggested elsewhere that do not support legacy instruction sets, ignore features critical to the existing software base, and also introduce design inefficiencies to RISC-style processor pipelines. CHERI Concentrate improves on the state-of-the-art region-encoding efficiency, solves important pipeline problems, and eases semantic restrictions of compressed encoding, allowing it to protect a full legacy software stack. We present the first quantitative analysis of compiled capability code, which we use to guide the design of the encoding format. We analyze and extend logic from the open-source CHERI prototype processor design on FPGA to demonstrate encoding efficiency, minimize delay of pointer arithmetic, and eliminate additional load-to-use delay. To verify correctness of our proposed high-performance logic, we present a HOL4 machine-checked proof of the decode and pointer-modify operations. Finally, we measure a 50\% to 75\% reduction in L2 misses for many compiled C-language benchmarks running under a commodity operating system using compressed 128-bit and 64-bit formats, demonstrating both compatibility with and increased performance over the uncompressed, 256-bit format.},
language = {en},
number = {10},
urldate = {2024-05-27},
journal = {IEEE Transactions on Computers},
author = {Woodruff, Jonathan and Joannou, Alexandre and Xia, Hongyan and Fox, Anthony and Norton, Robert M. and Chisnall, David and Davis, Brooks and Gudka, Khilan and Filardo, Nathaniel W. and Markettos, A. Theodore and Roe, Michael and Neumann, Peter G. and Watson, Robert N. M. and Moore, Simon W.},
month = oct,
year = {2019},
pages = {1455--1469},
file = {Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:/Users/akilan/Zotero/storage/3SZUIWQ5/Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:application/pdf},
}
@misc{noauthor_jemalloc_nodate,
title = {{JEMALLOC}},
url = {https://jemalloc.net/jemalloc.3.html},
urldate = {2025-01-15},
file = {JEMALLOC:/Users/akilan/Zotero/storage/QDEIEJ9N/jemalloc.3.html:text/html},
}
@misc{noauthor_arm_nodate,
title = {Arm {Architecture} {Reference} {Manual} for {A}-profile architecture},
url = {https://developer.arm.com/documentation/ddi0487/latest},
urldate = {2025-01-15},
file = {Arm Architecture Reference Manual for A-profile architecture:/Users/akilan/Zotero/storage/BVZSP7HA/latest.html:text/html},
}
@misc{noauthor_department_nodate,
title = {Department of {Computer} {Science} and {Technology} {CHERI}: {The} {Arm} {Morello} {Board}},
url = {https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html},
urldate = {2025-01-16},
file = {Department of Computer Science and Technology CHERI\: The Arm Morello Board:/Users/akilan/Zotero/storage/GCMNX8LY/cheri-morello.html:text/html},
}
@article{navarro_practical_nodate,
title = {Practical, transparent operating system support for superpages},
abstract = {Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer (TLB) to map a large physical memory region into a virtual address space. This dramatically increases TLB coverage, reduces TLB misses, and promises performance improvements for many applications. However, supporting superpages poses several challenges to the operating system, in terms of superpage allocation and promotion tradeoffs, fragmentation control, etc. We analyze these issues, and propose the design of an effective superpage management system. We implement it in FreeBSD on the Alpha CPU, and evaluate it on real workloads and benchmarks. We obtain substantial performance benefits, often exceeding 30\%; these benefits are sustained even under stressful workload scenarios.},
language = {en},
author = {Navarro, Juan},
file = {Navarro - Practical, transparent operating system support fo.pdf:/Users/akilan/Zotero/storage/R9MSCWQX/Navarro - Practical, transparent operating system support fo.pdf:application/pdf},
}
@misc{noauthor_ctsrd-cheritoooba_nodate,
title = {{CTSRD}-{CHERI}/{Toooba}: {RISC}-{V} {Core}; superscalar, out-of-order, multi-core capable; based on {RISCY}-{OOO} from {MIT}},
url = {https://github.com/CTSRD-CHERI/Toooba},
urldate = {2025-02-25},
file = {CTSRD-CHERI/Toooba\: RISC-V Core\; superscalar, out-of-order, multi-core capable\; based on RISCY-OOO from MIT:/Users/akilan/Zotero/storage/BQPSL2D6/Toooba.html:text/html},
}
@article{witaszczyk_pure-capability_nodate,
title = {Pure-capability third-party software for {Arm} {Morello} and {CHERI}-{RISC}-{V} {CheriBSD}},
language = {en},
author = {Witaszczyk, Konrad},
file = {Witaszczyk - Pure-capability third-party software for Arm Morel.pdf:/Users/akilan/Zotero/storage/549XSPL6/Witaszczyk - Pure-capability third-party software for Arm Morel.pdf:application/pdf},
}

65
docs/FutureTasks/docs.bbl Normal file
View File

@@ -0,0 +1,65 @@
% 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{noauthor_jemalloc_nodate}
\BIBentryALTinterwordspacing
``{JEMALLOC}.'' [Online]. Available: \url{https://jemalloc.net/jemalloc.3.html}
\BIBentrySTDinterwordspacing
\bibitem{navarro_practical_nodate}
J.~Navarro, ``\BIBforeignlanguage{en}{Practical, transparent operating system
support for superpages}.''
\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, ``\BIBforeignlanguage{en}{{CHERI} {Concentrate}:
{Practical} {Compressed} {Capabilities}},''
\emph{\BIBforeignlanguage{en}{IEEE Transactions on Computers}}, vol.~68,
no.~10, pp. 1455--1469, Oct. 2019. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/8703061/}
\BIBentrySTDinterwordspacing
\bibitem{noauthor_department_nodate}
\BIBentryALTinterwordspacing
``Department of {Computer} {Science} and {Technology} {CHERI}: {The} {Arm}
{Morello} {Board}.'' [Online]. Available:
\url{https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html}
\BIBentrySTDinterwordspacing
\bibitem{noauthor_ctsrd-cheritoooba_nodate}
\BIBentryALTinterwordspacing
``{CTSRD}-{CHERI}/{Toooba}: {RISC}-{V} {Core}; superscalar, out-of-order,
multi-core capable; based on {RISCY}-{OOO} from {MIT}.'' [Online]. Available:
\url{https://github.com/CTSRD-CHERI/Toooba}
\BIBentrySTDinterwordspacing
\bibitem{noauthor_arm_nodate}
\BIBentryALTinterwordspacing
``Arm {Architecture} {Reference} {Manual} for {A}-profile architecture.''
[Online]. Available:
\url{https://developer.arm.com/documentation/ddi0487/latest}
\BIBentrySTDinterwordspacing
\end{thebibliography}

View File

@@ -9,18 +9,19 @@ and will then expand into 2 potential paths:
- Cheri RISCV to prevent using the TLB.
- Allocator evaluation based on stripping instruction
calls for larger allocators like Jemalloc.
calls for larger allocators like Jemalloc\cite{noauthor_jemalloc_nodate}.
** 1. Current expirement: FAT pointer based range addresses
#+NAME: fig:FPBRA
#+CAPTION: FAT pointer implementation with Huge pages against a standard malloc allocator.
[[./HighOverviewArchitecture.drawio.png]]
The objective of this expirement was to ensure we can use the CHERI bounds as
tracking mechanism of allocations instead of using multiple TLB entries. Using
this approach we can use a single Huge page entry with bounds to ensure that
this approach we can use a single Huge page\cite{navarro_practical_nodate} entry with bounds to ensure that
the bounds (Which is the top and base address) can be extracted from the
pointer using the Cheri compressed bounds mechanism. We implemented a simple
pointer using the Cheri compressed bounds\cite{woodruff_cheri_2019} mechanism. We implemented a simple
allocator which uses this technique with a basic malloc and free.
*** Objectives
@@ -38,7 +39,7 @@ allocator which uses this technique with a basic malloc and free.
utilization?
*** Hardware
- ARM morello (Huge page size 1GB used)
- ARM morello\cite{noauthor_department_nodate} (Huge page size 1GB used)
*** Evaluation
We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
@@ -65,12 +66,13 @@ performance in more practical, real-world scenarios.
** 2. Cheri RISCV to prevent using the TLB
#+attr_latex: :width 200px
#+CAPTION: FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.
#+NAME: fig:RFPBRA
[[./MainOverview.png]]
In the current ARM Morello setup, address
translations rely on the TLB. The future approach
on RISC-V Tooba involves storing the offset directly within the pointer.
on RISC-V Tooba\cite{noauthor_ctsrd-cheritoooba_nodate} involves storing the offset directly within the pointer.
This is possible due to CHERIs capability model, which supports
fine-grained memory protection and can encode bounds within pointers.
Utilizing Bounds in CHERI for Block-Based Allocation:
@@ -92,54 +94,186 @@ and improving performance, especially for frequent memory operations.
** 3. Allocator evaluation based on stripping instruction calls for larger allocators
#+NAME: fig:MEMALLOC
#+CAPTION: Deprecating the use of THP with CHERI bound aware embedded mmap.
[[./memory_allocator.drawio.png]]
*** Box 1
*** Box 1 (Transparent huge pages)
#+BEGIN_COMMENT
The diagram above mentions 3 particular implementations. The first box which is the
standard THP(Transparent huge pages) utilised by modern allocators. THP initially
emphasises on doing smalled allocations and as the number of allocations grows
uses a technique which groups all smaller allocations together and when done
converts them into a large page of size 4mb in allocators such as jemalloc.
#+END_COMMENT
The diagram [[fig:MEMALLOC]] highlights three specific implementations, the
first of which is the standard Transparent Huge Pages (THP)
mechanism employed by modern memory allocators. THP initially
focuses on handling smaller memory allocations. As the volume
of allocations increases, it employs a strategy that consolidates
these smaller allocations into contiguous memory regions.
Once aggregated, these regions are subsequently converted
into larger memory pages, typically of size 4MB, as seen
in allocators like jemalloc. This approach optimizes memory
management by reducing fragmentation and improving performance
through the use of larger page sizes.
#+BEGIN_COMMENT
This approach does incur addtional operations such as grouping smaller allocations
chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
huge page is created the TLB misses are reduced.
#+END_COMMENT
This approach, however, introduces additional
overhead, including the operations required to consolidate
smaller allocations and modify Translation Lookaside Buffer (TLB)
entries. These modifications can initially increase the
likelihood of TLB misses, as the process of grouping and
reorganizing memory allocations temporarily disrupts the
efficiency of TLB utilization. It is only after the
successful creation of the huge page that the benefits
materialize, leading to a reduction in TLB misses due
to the improved alignment of memory access patterns with
the larger page size.
*** Box 2
*** Box 2 (Our current implementation)
#+BEGIN_COMMENT
Box 2 which refers to our current implementation always pre-allocates huge pages
and untilises CHERI bounds to track each allocation inside the huge page. Allowing
a single entry with the combination of bounds to provide block based behavoir in
physically contigous memory while ensuring a pointer can only access a regoin
within it's defined bounds.
#+END_COMMENT
Box 2 outlines the current implementation, which involves the
pre-allocation of huge pages and leverages CHERI
(Capability Hardware Enhanced RISC Instructions) bounds
to meticulously track each allocation within these pages.
This approach enables a single TLB entry, combined with
the precise bounds defined by CHERI capabilities, to
facilitate block-based memory management within physically
contiguous regions. By enforcing strict bounds on pointers,
the system ensures that each pointer can only access memory
within its explicitly defined region.
#+BEGIN_COMMENT
Another aspect to note is that the bounds can be of a dynamic size when defined. This is
in contrast to defining multiple page entries which need to be fixed sizes which means
they always incur multiple entries. In the current approach when the huge page size is
hit a new one is created. The limitaton of this is appraoch being we are limited to the
huge page set by the processor implementation (In our case the CHERI ARM v8.1).
#+END_COMMENT
*** Box 3
Another critical aspect of this implementation is the
ability to define bounds of dynamic sizes, which stands
in contrast to traditional approaches that rely on
fixed-size page entries. Fixed-size entries inherently
require multiple TLB entries, regardless of the actual
memory usage, leading to inefficiencies. In the current
approach, when the allocated memory within a huge page
reaches its capacity, a new huge page is allocated.
However, a notable limitation of this method is its
dependence on the maximum huge page size supported by
the underlying processor architecture. In this case,
the system is constrained by the huge page size defined
by the CHERI-enhanced ARM v8.1\cite{noauthor_arm_nodate} architecture. While this
approach offers flexibility in memory allocation and
reduces the need for multiple TLB entries, it is
ultimately bounded by the hardware's architectural specifications.
*** Box 3 (RISC-V implementation)
#+BEGIN_COMMENT
The 3rd box specifies an alternate appraoch by not using huge pages and required
memory is not required to be physically contigous. In this approach the pointer
stores all the metadata to the translation from virtual to physical addresses.
#+END_COMMENT
*** Building up from the work of Box 2 and Box 3
The third approach, as outlined in Box 3, deviates from the
use of huge pages and does not require memory to be
physically contiguous. In this model, each pointer
is designed to store comprehensive metadata at the pointer necessary
for the translation from virtual to physical addresses.
This metadata enables the system to manage memory allocations
without the constraints of physical contiguity, thereby
offering greater flexibility in memory utilization.
By embedding translation information directly within the
pointers, this approach eliminates the need for large,
contiguous memory regions and allows for more granular
and dynamic memory management.
*** Building up from the work of Box 2 and Box 3 (Side effects we can strip away)
#+BEGIN_COMMENT
Box 2 and 3 from a high overview there is only minor difference which can be noted
which is 1 uses huge pages and other does not. Both approaches can strip down the
number intructions needed in modern allocators (Stripping away the need transitioning
from smaller to larger pages). This document is yet to give an exact breakdown.
#+END_COMMENT
From a high-level perspective, the primary distinction between
Box 2 and Box 3 lies in the use of huge pages in the former
and their absence in the latter. Both approaches share
the common advantage of reducing the number of instructions
required in modern memory allocators by eliminating the
need for transitioning between smaller and larger pages.
This simplification streamlines memory management processes.
However, this document has not yet provided a detailed breakdown
or quantitative analysis of the specific performance implications
or trade-offs.
#+BEGIN_COMMENT
As seen to the right of the diagram is a sample snippet of TC malloc from the paper
(Beyond malloc efficiency to fleet allocators). This whole span function would not
be required in our approach. The other benefit being easier get the approach by
getting mmap embedded inside the allocator.
#+END_COMMENT
As illustrated to the right of the diagram, a sample snippet of
TC malloc from the paper Beyond malloc Efficiency to Fleet
Efficiency is provided. In the proposed approach, the entire
span function, which is essential in TC malloc, would become
unnecessary. Additionally, the approach offers the advantage
of simplifying memory management by integrating mmap directly
within the allocator. This integration eliminates the need for
separate mechanisms to handle memory mapping.
*** Evaluation:
#+BEGIN_COMMENT
- Amount of instructions that can be stripped away from the page aware
memory allocator.
- Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
- CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
emitted vs regular ARMv8 clang program with the same allocator).
#+END_COMMENT
- The number of instructions that can be eliminated from a
page-aware memory allocator by adopting the proposed approach.
- A comparative analysis of the memory allocator's performance
using wall-clock runtime measurements, both with and without
the modified mmap implementation.
- While CHERI Purecap introduces additional instructions, such
as bounds checks, the overall approach aims to determine
whether it reduces the total number of instructions when
compared to a traditional ARMv8 Clang program using the
same allocator. This involves evaluating the trade-offs
between the overhead of CHERI-specific instructions and
the potential reductions in allocator-emitted instructions.
** Current tasks on hand
1. To port over all chapters written to a
EuroSys Conferenece document and send over the
to the supervisory team for a review.
- This will then get send over to Jeremy
for an external review.
- Expands to a talk in the University
of Glasgow seminar.
- Concurrent suggestions of the Eurosys
submission till may.
2. Work on allocator evaluation based on stripping instruction calls for
larger allocators (Expirement agreed in the meeting).
3. Write to Cambridge a proposal for using the RISC-V expirement (2 weeks).
\bibliographystyle{IEEEtran}
\bibliography{FuturePlan.bib}

Binary file not shown.

View File

@@ -1,4 +1,4 @@
% Created 2025-02-25 Tue 10:21
% Created 2025-02-26 Wed 15:30
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
@@ -29,7 +29,7 @@
\section*{Future work}
\label{sec:org69c56b9}
\label{sec:orgda47b6e}
This documents is decision making to highlight
potential paths to take for this PhD.
We will initially talk about the current expirement
@@ -39,26 +39,27 @@ and will then expand into 2 potential paths:
\begin{itemize}
\item Cheri RISCV to prevent using the TLB.
\item Allocator evaluation based on stripping instruction
calls for larger allocators like Jemalloc.
calls for larger allocators like Jemalloc\cite{noauthor_jemalloc_nodate}.
\end{itemize}
\subsection*{1. Current expirement: FAT pointer based range addresses}
\label{sec:org72b7f3a}
\begin{center}
\label{sec:org3d72d8f}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./HighOverviewArchitecture.drawio.png}
\label{orge7449fe}
\end{center}
\caption{\label{fig:orgcd7570b}FAT pointer implementation with Huge pages against a standard malloc allocator.}
\end{figure}
The objective of this expirement was to ensure we can use the CHERI bounds as
tracking mechanism of allocations instead of using multiple TLB entries. Using
this approach we can use a single Huge page entry with bounds to ensure that
this approach we can use a single Huge page\cite{navarro_practical_nodate} entry with bounds to ensure that
the bounds (Which is the top and base address) can be extracted from the
pointer using the Cheri compressed bounds mechanism. We implemented a simple
pointer using the Cheri compressed bounds\cite{woodruff_cheri_2019} mechanism. We implemented a simple
allocator which uses this technique with a basic malloc and free.
\subsubsection*{Objectives}
\label{sec:org6aecc9c}
\label{sec:org9153cb3}
\begin{itemize}
\item How does the utilization of bounds for tracking memory
allocations, in addition to security purposes, affect
@@ -75,13 +76,13 @@ utilization?
\end{itemize}
\subsubsection*{Hardware}
\label{sec:org679e3d0}
\label{sec:orgd94c91f}
\begin{itemize}
\item ARM morello (Huge page size 1GB used)
\item ARM morello\cite{noauthor_department_nodate} (Huge page size 1GB used)
\end{itemize}
\subsubsection*{Evaluation}
\label{sec:org00dd6a3}
\label{sec:orgc8016e9}
We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
the default memory allocator for CHERIBSD, to assess the
performance improvements enabled by a CHERI-based huge page-aware
@@ -97,7 +98,7 @@ realworld C programs, allowing us to assess the allocators
performance in more practical, real-world scenarios.
\subsubsection*{limitation}
\label{sec:orga9c8652}
\label{sec:orgec3f8c5}
\begin{itemize}
\item Using Huge page still requires a TLB entry which could be mitigated
(Refer to the FPGA work).
@@ -107,16 +108,17 @@ bypass the TLB for address translation.
\subsection*{2. Cheri RISCV to prevent using the TLB}
\label{sec:orgff20030}
\label{sec:org54690ae}
\begin{center}
\begin{figure}[htbp]
\centering
\includegraphics[width=200px]{./MainOverview.png}
\label{orge10034a}
\end{center}
\caption{\label{fig:org7fecd7d}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
\end{figure}
In the current ARM Morello setup, address
translations rely on the TLB. The future approach
on RISC-V Tooba involves storing the offset directly within the pointer.
on RISC-V Tooba\cite{noauthor_ctsrd-cheritoooba_nodate} involves storing the offset directly within the pointer.
This is possible due to CHERIs capability model, which supports
fine-grained memory protection and can encode bounds within pointers.
Utilizing Bounds in CHERI for Block-Based Allocation:
@@ -128,7 +130,7 @@ implementation of a block-based allocator that can efficiently manage memory
allocations and deallocations within defined bounds. Bypassing the TLB in RISC-V Tooba.
\subsubsection*{Hardware modifications}
\label{sec:org684e10b}
\label{sec:orgc9c424e}
The Bluespec design of the RISC-V processor will be modified to allow
certain memory operations to bypass the TLB. This means that when a pointer
with encoded offset and bounds is used, the system can directly compute the
@@ -137,65 +139,145 @@ dependency on the TLB, decreasing latency.
and improving performance, especially for frequent memory operations.
\subsection*{3. Allocator evaluation based on stripping instruction calls for larger allocators}
\label{sec:orge8c4354}
\label{sec:org50ff3ae}
\begin{center}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./memory_allocator.drawio.png}
\label{orgaff7895}
\end{center}
\caption{\label{fig:org71f4ddc}Deprecating the use of THP with CHERI bound aware embedded mmap.}
\end{figure}
\subsubsection*{Box 1}
\label{sec:org19bde19}
The diagram above mentions 3 particular implementations. The first box which is the
standard THP(Transparent huge pages) utilised by modern allocators. THP initially
emphasises on doing smalled allocations and as the number of allocations grows
uses a technique which groups all smaller allocations together and when done
converts them into a large page of size 4mb in allocators such as jemalloc.
\subsubsection*{Box 1 (Transparent huge pages)}
\label{sec:orgcd7e5f0}
The diagram \ref{fig:org71f4ddc} highlights three specific implementations, the
first of which is the standard Transparent Huge Pages (THP)
mechanism employed by modern memory allocators. THP initially
focuses on handling smaller memory allocations. As the volume
of allocations increases, it employs a strategy that consolidates
these smaller allocations into contiguous memory regions.
Once aggregated, these regions are subsequently converted
into larger memory pages, typically of size 4MB, as seen
in allocators like jemalloc. This approach optimizes memory
management by reducing fragmentation and improving performance
through the use of larger page sizes.
This approach does incur addtional operations such as grouping smaller allocations
chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
huge page is created the TLB misses are reduced.
This approach, however, introduces additional
overhead, including the operations required to consolidate
smaller allocations and modify Translation Lookaside Buffer (TLB)
entries. These modifications can initially increase the
likelihood of TLB misses, as the process of grouping and
reorganizing memory allocations temporarily disrupts the
efficiency of TLB utilization. It is only after the
successful creation of the huge page that the benefits
materialize, leading to a reduction in TLB misses due
to the improved alignment of memory access patterns with
the larger page size.
\subsubsection*{Box 2}
\label{sec:org31e2b6f}
Box 2 which refers to our current implementation always pre-allocates huge pages
and untilises CHERI bounds to track each allocation inside the huge page. Allowing
a single entry with the combination of bounds to provide block based behavoir in
physically contigous memory while ensuring a pointer can only access a regoin
within it's defined bounds.
\subsubsection*{Box 2 (Our current implementation)}
\label{sec:org41ee7a8}
Box 2 outlines the current implementation, which involves the
pre-allocation of huge pages and leverages CHERI
(Capability Hardware Enhanced RISC Instructions) bounds
to meticulously track each allocation within these pages.
This approach enables a single TLB entry, combined with
the precise bounds defined by CHERI capabilities, to
facilitate block-based memory management within physically
contiguous regions. By enforcing strict bounds on pointers,
the system ensures that each pointer can only access memory
within its explicitly defined region.
Another aspect to note is that the bounds can be of a dynamic size when defined. This is
in contrast to defining multiple page entries which need to be fixed sizes which means
they always incur multiple entries. In the current approach when the huge page size is
hit a new one is created. The limitaton of this is appraoch being we are limited to the
huge page set by the processor implementation (In our case the CHERI ARM v8.1).
Another critical aspect of this implementation is the
ability to define bounds of dynamic sizes, which stands
in contrast to traditional approaches that rely on
fixed-size page entries. Fixed-size entries inherently
require multiple TLB entries, regardless of the actual
memory usage, leading to inefficiencies. In the current
approach, when the allocated memory within a huge page
reaches its capacity, a new huge page is allocated.
However, a notable limitation of this method is its
dependence on the maximum huge page size supported by
the underlying processor architecture. In this case,
the system is constrained by the huge page size defined
by the CHERI-enhanced ARM v8.1\cite{noauthor_arm_nodate} architecture. While this
approach offers flexibility in memory allocation and
reduces the need for multiple TLB entries, it is
ultimately bounded by the hardware's architectural specifications.
\subsubsection*{Box 3}
\label{sec:org28e0813}
The 3rd box specifies an alternate appraoch by not using huge pages and required
memory is not required to be physically contigous. In this approach the pointer
stores all the metadata to the translation from virtual to physical addresses.
\subsubsection*{Box 3 (RISC-V implementation)}
\label{sec:org9f9a21d}
The third approach, as outlined in Box 3, deviates from the
use of huge pages and does not require memory to be
physically contiguous. In this model, each pointer
is designed to store comprehensive metadata at the pointer necessary
for the translation from virtual to physical addresses.
This metadata enables the system to manage memory allocations
without the constraints of physical contiguity, thereby
offering greater flexibility in memory utilization.
By embedding translation information directly within the
pointers, this approach eliminates the need for large,
contiguous memory regions and allows for more granular
and dynamic memory management.
\subsubsection*{Building up from the work of Box 2 and Box 3}
\label{sec:org12eb9a0}
Box 2 and 3 from a high overview there is only minor difference which can be noted
which is 1 uses huge pages and other does not. Both approaches can strip down the
number intructions needed in modern allocators (Stripping away the need transitioning
from smaller to larger pages). This document is yet to give an exact breakdown.
\subsubsection*{Building up from the work of Box 2 and Box 3 (Side effects we can strip away)}
\label{sec:org3dac27a}
From a high-level perspective, the primary distinction between
Box 2 and Box 3 lies in the use of huge pages in the former
and their absence in the latter. Both approaches share
the common advantage of reducing the number of instructions
required in modern memory allocators by eliminating the
need for transitioning between smaller and larger pages.
This simplification streamlines memory management processes.
However, this document has not yet provided a detailed breakdown
or quantitative analysis of the specific performance implications
or trade-offs.
As seen to the right of the diagram is a sample snippet of TC malloc from the paper
(Beyond malloc efficiency to fleet allocators). This whole span function would not
be required in our approach. The other benefit being easier get the approach by
getting mmap embedded inside the allocator.
As illustrated to the right of the diagram, a sample snippet of
TC malloc from the paper Beyond malloc Efficiency to Fleet
Efficiency is provided. In the proposed approach, the entire
span function, which is essential in TC malloc, would become
unnecessary. Additionally, the approach offers the advantage
of simplifying memory management by integrating mmap directly
within the allocator. This integration eliminates the need for
separate mechanisms to handle memory mapping.
\subsubsection*{Evaluation:}
\label{sec:org6f6e966}
\label{sec:org84b9699}
\begin{itemize}
\item Amount of instructions that can be stripped away from the page aware
memory allocator.
\item Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
\item CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
emitted vs regular ARMv8 clang program with the same allocator).
\item The number of instructions that can be eliminated from a
page-aware memory allocator by adopting the proposed approach.
\item A comparative analysis of the memory allocator's performance
using wall-clock runtime measurements, both with and without
the modified mmap implementation.
\item While CHERI Purecap introduces additional instructions, such
as bounds checks, the overall approach aims to determine
whether it reduces the total number of instructions when
compared to a traditional ARMv8 Clang program using the
same allocator. This involves evaluating the trade-offs
between the overhead of CHERI-specific instructions and
the potential reductions in allocator-emitted instructions.
\end{itemize}
\subsection*{Current tasks on hand}
\label{sec:org3fd32dc}
\begin{enumerate}
\item To port over all chapters written to a
EuroSys Conferenece document and send over the
to the supervisory team for a review.
\begin{itemize}
\item This will then get send over to Jeremy
for an external review.
\item Expands to a talk in the University
of Glasgow seminar.
\item Concurrent suggestions of the Eurosys
submission till may.
\end{itemize}
\item Work on allocator evaluation based on stripping instruction calls for
larger allocators (Expirement agreed in the meeting).
\item Write to Cambridge a proposal for using the RISC-V expirement (2 weeks).
\end{enumerate}
\bibliographystyle{IEEEtran}
\bibliography{FuturePlan.bib}
\end{document}