2038 lines
112 KiB
TeX
2038 lines
112 KiB
TeX
%%
|
||
%% This is file `sample-sigconf-authordraft.tex',
|
||
%% generated with the docstrip utility.
|
||
%%
|
||
%% The original source files were:
|
||
%%
|
||
%% samples.dtx (with options: `all,proceedings,bibtex,authordraft')
|
||
%%
|
||
%% IMPORTANT NOTICE:
|
||
%%
|
||
%% For the copyright see the source file.
|
||
%%
|
||
%% Any modified versions of this file must be renamed
|
||
%% with new filenames distinct from sample-sigconf-authordraft.tex.
|
||
%%
|
||
%% For distribution of the original source see the terms
|
||
%% for copying and modification in the file samples.dtx.
|
||
%%
|
||
%% This generated file may be distributed as long as the
|
||
%% original source files, as listed above, are part of the
|
||
%% same distribution. (The sources need not necessarily be
|
||
%% in the same archive or directory.)
|
||
%%
|
||
%%
|
||
%% Commands for TeXCount
|
||
%TC:macro ~\cite [option:text,text]
|
||
%TC:macro ~\citep [option:text,text]
|
||
%TC:macro ~\citet [option:text,text]
|
||
%TC:envir table 0 1
|
||
%TC:envir table* 0 1
|
||
%TC:envir tabular [ignore] word
|
||
%TC:envir displaymath 0 word
|
||
%TC:envir math 0 word
|
||
%TC:envir comment 0 0
|
||
%%
|
||
%%
|
||
%% The first command in your LaTeX source must be the \documentclass
|
||
%% command.
|
||
%%
|
||
%% For submission and review of your manuscript please change the
|
||
%% command to \documentclass[manuscript, screen, review]{acmart}.
|
||
%%
|
||
%% When submitting camera ready or to TAPS, please change the command
|
||
%% to \documentclass[sigconf]{acmart} or whichever template is required
|
||
%% for your publication.
|
||
%%
|
||
%%
|
||
\documentclass[sigconf,authordraft]{acmart}
|
||
\usepackage{listings}
|
||
\usepackage{algorithm}
|
||
\usepackage{algpseudocode}
|
||
\usepackage{amsmath}
|
||
|
||
\usepackage{lipsum}
|
||
\usepackage{stfloats}
|
||
\usepackage{grffile}
|
||
\usepackage{hyperref}
|
||
|
||
\usepackage{multicol}
|
||
\usepackage{graphicx}
|
||
\usepackage{subcaption}
|
||
\usepackage{caption}
|
||
\usepackage{graphicx}
|
||
|
||
\lstset{basicstyle=\small\ttfamily,columns=fullflexible}
|
||
|
||
%%
|
||
%% \BibTeX command to typeset BibTeX logo in the docs
|
||
\AtBeginDocument{%
|
||
\providecommand\BibTeX{{%
|
||
Bib\TeX}}}
|
||
|
||
%% Rights management information. This information is sent to you
|
||
%% when you complete the rights form. These commands have SAMPLE
|
||
%% values in them; it is your responsibility as an author to replace
|
||
%% the commands and values with those provided to you when you
|
||
%% complete the rights form.
|
||
\setcopyright{acmlicensed}
|
||
\copyrightyear{2018}
|
||
\acmYear{2018}
|
||
\acmDOI{XXXXXXX.XXXXXXX}
|
||
|
||
%% These commands are for a PROCEEDINGS abstract or paper.
|
||
\acmConference[Conference acronym 'XX]{Make sure to enter the correct
|
||
conference title from your rights confirmation emai}{June 03--05,
|
||
2018}{Woodstock, NY}
|
||
%%
|
||
%% Uncomment \acmBooktitle if the title of the proceedings is different
|
||
%% from ``Proceedings of ...''!
|
||
%%
|
||
%%\acmBooktitle{Woodstock '18: ACM Symposium on Neural Gaze Detection,
|
||
%% June 03--05, 2018, Woodstock, NY}
|
||
\acmISBN{978-1-4503-XXXX-X/18/06}
|
||
|
||
|
||
%%
|
||
%% Submission ID.
|
||
%% Use this when submitting an article to a sponsored event. You'll
|
||
%% receive a unique submission ID from the organizers
|
||
%% of the event, and this ID should be used as the parameter to this command.
|
||
%%\acmSubmissionID{123-A56-BU3}
|
||
|
||
%%
|
||
%% For managing citations, it is recommended to use bibliography
|
||
%% files in BibTeX format.
|
||
%%
|
||
%% You can then either use BibTeX with the ACM-Reference-Format style,
|
||
%% or BibLaTeX with the acmnumeric or acmauthoryear sytles, that include
|
||
%% support for advanced citation of software artefact from the
|
||
%% biblatex-software package, also separately available on CTAN.
|
||
%%
|
||
%% Look at the sample-*-biblatex.tex files for templates showcasing
|
||
%% the biblatex styles.
|
||
%%
|
||
|
||
%%
|
||
%% The majority of ACM publications use numbered citations and
|
||
%% references. The command ~\citestyle{authoryear} switches to the
|
||
%% "author year" style.
|
||
%%
|
||
%% If you are preparing content for an event
|
||
%% sponsored by ACM SIGGRAPH, you must use the "author year" style of
|
||
%% citations and references.
|
||
%% Uncommenting
|
||
%% the next command will enable that style.
|
||
%%~\citestyle{acmauthoryear}
|
||
|
||
|
||
%%
|
||
%% end of the preamble, start of the body of the document source.
|
||
\begin{document}
|
||
|
||
%%
|
||
%% The "title" commanSd has an optional parameter,
|
||
%% allowing the author to define a "short title" to be used in page headers.
|
||
\title{FAT allocator}
|
||
|
||
%%
|
||
%% The "author" command and its associated commands are used to define
|
||
%% the authors and their affiliations.
|
||
%% Of note is the shared affiliation of the first two authors, and the
|
||
%% "authornote" and "authornotemark" commands
|
||
%% used to denote shared contribution to the research.
|
||
\author{Akilan Selvacoumar}
|
||
% \authornote{Both authors contributed equally to this research.}
|
||
% \email{as251@hw.ac.uk}
|
||
% \orcid{1234-5678-9012}
|
||
% \author{G.K.M. Tobin}
|
||
\authornotemark[1]
|
||
\email{as251@hw.ac.uk}
|
||
\affiliation{%
|
||
\institution{Heriot Watt}
|
||
\city{Edinburgh}
|
||
\state{Scotland}
|
||
\country{United Kingdom}
|
||
}
|
||
|
||
% \author{Lars Th{\o}rv{\"a}ld}
|
||
% \affiliation{%
|
||
% \institution{The Th{\o}rv{\"a}ld Group}
|
||
% \city{Hekla}
|
||
% \country{Iceland}}
|
||
% \email{larst@affiliation.org}
|
||
|
||
% \author{Valerie B\'eranger}
|
||
% \affiliation{%
|
||
% \institution{Inria Paris-Rocquencourt}
|
||
% \city{Rocquencourt}
|
||
% \country{France}
|
||
% }
|
||
|
||
% \author{Aparna Patel}
|
||
% \affiliation{%
|
||
% \institution{Rajiv Gandhi University}
|
||
% \city{Doimukh}
|
||
% \state{Arunachal Pradesh}
|
||
% \country{India}}
|
||
|
||
% \author{Huifen Chan}
|
||
% \affiliation{%
|
||
% \institution{Tsinghua University}
|
||
% \city{Haidian Qu}
|
||
% \state{Beijing Shi}
|
||
% \country{China}}
|
||
|
||
% \author{Charles Palmer}
|
||
% \affiliation{%
|
||
% \institution{Palmer Research Laboratories}
|
||
% \city{San Antonio}
|
||
% \state{Texas}
|
||
% \country{USA}}
|
||
% \email{cpalmer@prl.com}
|
||
|
||
% \author{John Smith}
|
||
% \affiliation{%
|
||
% \institution{The Th{\o}rv{\"a}ld Group}
|
||
% \city{Hekla}
|
||
% \country{Iceland}}
|
||
% \email{jsmith@affiliation.org}
|
||
|
||
% \author{Julius P. Kumquat}
|
||
% \affiliation{%
|
||
% \institution{The Kumquat Consortium}
|
||
% \city{New York}
|
||
% \country{USA}}
|
||
% \email{jpkumquat@consortium.net}
|
||
|
||
%%
|
||
%% By default, the full list of authors will be used in the page
|
||
%% headers. Often, this list is too long, and will overlap
|
||
%% other information printed in the page headers. This command allows
|
||
%% the author to define a more concise list
|
||
%% of authors' names for this purpose.
|
||
% \renewcommand{\shortauthors}{Trovato et al.}
|
||
|
||
%%
|
||
%% The abstract is a short summary of the work to be presented in the
|
||
%% article.
|
||
\begin{abstract}
|
||
% The increasing disparity between application workloads and the capacity of s (TLB)
|
||
% has prompted researchers to explore innovative solutions to mitigate this gap. One such approach involves
|
||
% leveraging physically contiguous memory and the use of huge pages to optimize TLB utilization. Huge pages,
|
||
% which group multiple smaller pages into larger ones, reduce TLB miss rates by decreasing the number of entries
|
||
% required in the TLB, thus improving overall performance. Concurrently, advancements in hardware-level system
|
||
% security, exemplified by the Capability Hardware Enhanced RISC Instructions (CHERI) architecture, offer
|
||
% additional opportunities for improving memory management and security.
|
||
|
||
% CHERI introduces capability-based addressing, a novel approach that enhances system security by
|
||
% associating capabilities with memory pointers. These capabilities restrict access to memory regions,
|
||
% thereby fortifying the system against various security threats. Importantly, the mechanisms implemented in
|
||
% CHERI for enforcing memory protection can also serve as accelerators for standard user-space memory allocators.
|
||
% By leveraging capability-based addressing, memory allocators can efficiently manage memory resources, ensure
|
||
% robust security measures are in place, and potentially enhance performance through the integration of huge pages,
|
||
% further improving TLB efficiency and memory handling.
|
||
|
||
% Through our evaluation using both micro and macro benchmarks,
|
||
% we show that our allocator can reduce TLB misses by up to 90\%,
|
||
% leading to substantial improvements in wall clock runtimes for memory-intensive
|
||
% applications.
|
||
|
||
% The increasing disparity between application workloads and the capacity of translation lookaside buffers (TLBs) has prompted researchers
|
||
% to explore solutions to mitigate the extra clock cycles incurred during a TLB miss. One such approach involves leveraging physically contiguous memory
|
||
% and the use of huge pages. Concurrently, advancements in hardware-level system security—exemplified by the Capability Hardware
|
||
% Enhanced RISC Instructions (CHERI) architecture—offer additional opportunities for improving TLB performance. CHERI introduces
|
||
% capability-based addressing, a novel approach that enhances system security by associating capabilities with memory pointers. By leveraging capability-based
|
||
% addressing, we introduce a memory allocator that can integrate block-based allocations within huge pages. Through our evaluation using both micro and macro benchmarks, we show that
|
||
% our allocator can reduce TLB misses by up to 90\%, leading to improvements in wall clock runtimes for memory-intensive applications.
|
||
|
||
% The increasing gap between workload memory requirements and the capacity of translation lookaside buffers (TLBs) in hardware cache management of modern processors means that TLB misses
|
||
% are more frequent, costing additional clock cycles and impacting runtime performance. One solution that has been explored is to use physically contiguous
|
||
% memory in conjunction with huge pages.
|
||
|
||
% The contribution is an alternative approach by exploiting capability-based addressing in the
|
||
% CHERI architecture. This paper presents a new memory allocator called Fat Address Translations (FAT) which associates capabilities with memory pointers by integrating
|
||
% block-based allocations within huge pages. When the FAT allocator is ran independently and embedded inside Jemalloc, it reduces by up to 99\% walking the TLB hierarchy. This leads to
|
||
% decreasing runtimes for memory read and write intensive applications.
|
||
% The FAT allocator when ran independently and embedded inside Jemalloc reduces walking the TLB hierarchy by upto 90\%, which leads to decreasing runtimes
|
||
% for memory read and write intensive applications.
|
||
|
||
The widening gap between application memory demands and the limited capacity of hardware Translation Lookaside Buffers (TLBs)
|
||
in modern processors leads to frequent TLB misses, incurring significant performance penalties due to additional clock cycles
|
||
spent on page table walks. A common mitigation strategy involves the use of physically contiguous memory and huge pages to
|
||
reduce TLB pressure.
|
||
|
||
This paper introduces a solution that leverages capability-based addressing in the CHERI architecture with huge pages.
|
||
We present Fat Address Translations (FAT), a memory allocator that embeds allocation metadata directly within
|
||
pointer capabilities and manages memory in block-based allocations within huge pages. By encoding allocation bounds in capabilities,
|
||
FAT enables more efficient pointer dereferencing and reduces reliance on smaller page table entry lookups. Our evaluation shows that FAT,
|
||
both as a standalone allocator and when integrated into Jemalloc, reduces TLB hierarchy walks by up to 99\% in contrast to standard system allocators and improves runtime performance for memory read intensive applications.
|
||
This demonstrates that capability-based addressing can repurposed to mitigate TLB pressure.
|
||
\end{abstract}
|
||
|
||
%%
|
||
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
|
||
%% Please copy and paste the code instead of the example below.
|
||
% %%
|
||
% \begin{CCSXML}
|
||
% <ccs2012>
|
||
% <concept>
|
||
% <concept_id>00000000.0000000.0000000</concept_id>
|
||
% <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
|
||
% <concept_significance>500</concept_significance>
|
||
% </concept>
|
||
% <concept>
|
||
% <concept_id>00000000.00000000.00000000</concept_id>
|
||
% <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
|
||
% <concept_significance>300</concept_significance>
|
||
% </concept>
|
||
% <concept>
|
||
% <concept_id>00000000.00000000.00000000</concept_id>
|
||
% <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
|
||
% <concept_significance>100</concept_significance>
|
||
% </concept>
|
||
% <concept>
|
||
% <concept_id>00000000.00000000.00000000</concept_id>
|
||
% <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
|
||
% <concept_significance>100</concept_significance>
|
||
% </concept>
|
||
% </ccs2012>
|
||
% \end{CCSXML}
|
||
|
||
% \ccsdesc[500]{Do Not Use This Code~Generate the Correct Terms for Your Paper}
|
||
% \ccsdesc[300]{Do Not Use This Code~Generate the Correct Terms for Your Paper}
|
||
% \ccsdesc{Do Not Use This Code~Generate the Correct Terms for Your Paper}
|
||
% \ccsdesc[100]{Do Not Use This Code~Generate the Correct Terms for Your Paper}
|
||
|
||
%%
|
||
%% Keywords. The author(s) should pick words that accurately describe
|
||
%% the work being presented. Separate the keywords with commas.
|
||
% \keywords{Do, Not, Us, This, Code, Put, the, Correct, Terms, for,
|
||
% Your, Paper}
|
||
%% A "teaser" image appears between the author and affiliation
|
||
%% information and the body of the document, and typically spans the
|
||
%% page.
|
||
% \begin{teaserfigure}
|
||
% \includegraphics[width=\textwidth]{sampleteaser}
|
||
% \caption{Seattle Mariners at Spring Training, 2010.}
|
||
% \Description{Enjoying the baseball game from the third-base
|
||
% seats. Ichiro Suzuki preparing to bat.}
|
||
% \label{fig:teaser}
|
||
% \end{teaserfigure}
|
||
|
||
% \received{20 February 2007}
|
||
% \received[revised]{12 March 2009}
|
||
% \received[accepted]{5 June 2009}
|
||
|
||
%%
|
||
%% This command processes the author and affiliation and title
|
||
%% information and builds the first part of the formatted document.
|
||
\maketitle
|
||
|
||
\section{Introduction}
|
||
% In the dynamic landscape of computing, the pursuit of optimal performance is a constant endeavor,
|
||
% especially as applications evolve to handle increasingly complex workloads.
|
||
% One critical aspect influencing performance is memory management, where efficient
|
||
% utilization of resources is paramount. s (TLBs) play a
|
||
% pivotal role in this regard, expediting memory access by storing recently accessed memory translations.
|
||
% However, as applications grow in size and complexity, the capacity of TLBs often struggles to
|
||
% keep pace, leading to performance bottlenecks~\cite{mittalsurvey2017}. To address this challenge, researchers have
|
||
% turned to innovative solutions, one of which involves harnessing the benefits of huge pages.
|
||
% Huge pages, also known as large pages, allow for the allocation of memory in significantly
|
||
% larger chunks compared to traditional small pages. By reducing the number of TLB entries
|
||
% needed to access a given amount of memory, huge pages offer a potential avenue for optimizing
|
||
% TLB utilization and thereby enhancing overall system performance.
|
||
|
||
% Simultaneously, advancements in hardware-level security, such as the Capability Hardware
|
||
% Enhanced RISC Instructions (CHERI) architecture, present additional opportunities for
|
||
% performance enhancement. CHERI's capability-based addressing approach not only strengthens
|
||
% system security by tightly controlling memory access but also provides avenues for
|
||
% accelerating memory management operations.
|
||
|
||
In computing, achieving high performance is an ongoing challenge, especially as
|
||
modern applications handle increasingly memory intensive workloads.
|
||
% Performance referring to memory access rather than compute bound.
|
||
Memory management is a key factor in reducing the time it takes to access a memory region.
|
||
A Translation Lookaside Buffer (TLB) is a specialised cache in the memory management unit (MMU).
|
||
It reduces the time required to convert virtual addresses to physical addresses. When a program accesses
|
||
data in memory, the MMU first checks the TLB for a matching entry and avoids the slow process of
|
||
accessing the page tables situated in memory.
|
||
TLBs are crucial in speeding up memory access by caching recent
|
||
memory address translations. The TLB hierarchy~\cite{TLBHierarchy} comprises of a smaller, faster L1 TLB situated close to the processor core and a larger
|
||
slightly slower L2 TLB, both of which are usually private to each core thereby reducing the latency associated with page table lookups.
|
||
However, as applications grow more complex the TLBs often cannot keep up with the number of translation entries leading to more TLB misses which requires walking
|
||
the TLB hierarchy and this leads to performance slowdowns~\cite{mittal_survey_2017}.
|
||
To tackle this issue, researchers have explored new solutions, including the use of
|
||
huge pages~\cite{panwar_hawkeye_2019}.
|
||
|
||
Huge pages also known as large pages allow for the allocation of memory in significantly larger chunks
|
||
compared to traditional small pages which leads to fewer number of TLB entries needed to access a given amount
|
||
of memory. Huge pages offer a potential avenue for optimising TLBs which are used by reducing the number
|
||
of entries needed to map large memory regions. This not only decreases the frequency of
|
||
TLB misses but also lowers the overhead associated with address translation in regards to traversing the TLB cache
|
||
hierarchy and therefore minimising these bottlenecks.
|
||
% huge pages can improve system performance in aspects such as speeding
|
||
% up memory-intensive applications, reducing latency in data access and enhancing throughput for
|
||
% workloads that rely heavily on large datasets.
|
||
|
||
% Ryad's comment:
|
||
% If the TLB's are linked to a core. Will they behave differently for multi-cores? and who manages this? I believe Cheri is not single-core.
|
||
% Did you cover this at some point in your work?
|
||
% Answer: The focus on this paper is on single core execution.
|
||
|
||
Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
|
||
~\cite{woodruff_cheri_2014} which are standard 64-bit pointers that are replaced with capabilities with 128-bit or 256-bit
|
||
encoding scheme which consists of both the address and metadata. The metadata includes bounds, permissions and validity of the pointer
|
||
which forms a capability. This transformation of larger pointers enforces strict memory
|
||
safety as capabilities prevent arbitrary pointer arithmetic and unauthorised memory access.
|
||
CHERI's capability-based addressing approach not
|
||
only strengthens system security by tightly controlling memory access but also opens avenues for optimising memory management
|
||
operations. By integrating CHERI's compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, one of the contribution is demonstrating that it is possible to track, manage
|
||
large and physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces the TLB pressure by minimising the number of
|
||
entries required to map extensive memory regions thereby decreasing TLB misses and improving address translation performance.
|
||
Furthermore, this paper introduces the Fat Address Translations(FAT) allocator which accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
|
||
memory allocations by emulating block allocations on physically contiguous memory to reduce the TLB pressure. The contributions for the following paper are as follows:
|
||
\begin{itemize}
|
||
\item \textbf{FAT Addresses Translations}: Introduces FAT that include memory bounds, allowing
|
||
efficient tracking and management of physically contiguous memory regions (Section ~\ref{sec:FatPointerTranslations}).
|
||
|
||
\item \textbf{CHERI's Capability-based Optimisation}: Demonstrates how CHERI's architecture can be
|
||
used to optimise memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
|
||
(Section ~\ref{sec:128bitCompressedBounds}).
|
||
|
||
\item \textbf{Memory Allocation Algorithms (FAT allocator)}: Presents an algorithm for allocating, freeing
|
||
physically contiguous memory , and integrating huge pages with CHERI's capability-based bounds for enhanced memory management
|
||
(Section ~\ref{sec:MemoryAllocator}).
|
||
|
||
\item \textbf{Modified Jemalloc Memory Mapping with FAT allocator}: Modification to Jemalloc with the FAT allocator to support physically contiguous
|
||
memory allocation using a block-based strategy with capability-based addressing (Section ~\ref{sec:JemallocFATAllocator}).
|
||
\end{itemize}
|
||
|
||
Through evaluating micro and macro benchmarks the FAT allocator though the use of CHERI's capabilities and huge pages demonstrates the allocator's ability
|
||
to reduce TLB walks by up to 99\% which yields to improvements of wall clock runtimes by upto 6\% for memory-intensive
|
||
applications. While its impact on larger and computation-heavy workloads is less pronounced.
|
||
The proposed allocator shows strong potential for advancing memory management in scenarios requiring
|
||
high memory throughput by reducing the address translation overhead.
|
||
|
||
\section{Related work}
|
||
\label{sec:org0e192da}
|
||
|
||
\subsection{Huge Pages}
|
||
% A segment~\cite{basu_efficient_nodate} can be viewed as mapping between contiguous virtual
|
||
% memory and contiguous physical memory. The property of a
|
||
% segment allows it to be larger than a page. Direct Segment allows the user to set a single segment
|
||
% for an application. Two registers are added to mark the start
|
||
% and end of the segment. Any virtual address within this region
|
||
% can be translated by adding the fixed offset between the virtual
|
||
% and physical address.
|
||
Increasing TLB reach\cite{TLBReach} 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 which are backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
|
||
. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues.
|
||
|
||
% Alternate segment technique
|
||
% - JayneelGandhi,ArkapravaBasu,MarkD.Hill,andMichaelM.Swift.2014.Efficientmemoryvirtualization:Reducing
|
||
For instance, allocating 1 MB with 4 KB base pages requires 256 PTEs (Page Table Entries) and in contrast using a 2 MB huge page would waste
|
||
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium~\cite{IntelItanium} which
|
||
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organise huge
|
||
pages and without significant changes to the conventional page table. It only helps reduce page walk overheads.
|
||
Huge page tunable base page size permits the OS to adjust the base page, but still faces internal fragmentation problems
|
||
with huge page recommending a base page size of no more than 16 KB. Shadow Superpage~\cite{Shadow_superpages} introduces a new translation level
|
||
in the memory controller to merge non-contiguous physical pages into a huge page in a shadow memory space by extending
|
||
TLB coverage. However, this approach requires all memory traffic to be translated again in the memory controller
|
||
resulting in additional latency for memory accesses.
|
||
|
||
\subsection{Direct Segment}
|
||
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.
|
||
This concept of segmentation has seen a resurgence in some modern approaches that aim to enhance
|
||
translation coverage by designating specific areas in the virtual address space.
|
||
|
||
This method allows programmers to explicitly define
|
||
a single segment for applications requiring significant memory. It introduces two new
|
||
registers to the system, which indicate the start and end of this segment.
|
||
Virtual addresses within this segment are translated by calculating
|
||
the offset from the virtual start address and applying this offset to the
|
||
physical start address. This straightforward method simplifies the translation
|
||
process for large memory areas but requires significant modifications to the
|
||
source code of applications.
|
||
|
||
\subsection{Redundant Memory Mapping (RMM)}
|
||
Redundant Memory Mappings (RMM)~\cite{karakostas_redundant_2015} enhance memory management by introducing an additional range table
|
||
that pre-allocates contiguous physical pages for large memory allocations thus creating ranges that
|
||
are both virtually and physically contiguous. This approach simplifies address translation
|
||
by adding ranges. RMM is similar to Direct Segment with the support of multiple
|
||
ranges and operates transparently to programmers. No source code modifications is required on the programmers
|
||
side. The range table which is separate from the conventional page table holds the mappings for these
|
||
large allocations. To determine which range an address belongs to, RMM compares the address
|
||
against all range boundaries. Since this process is computationally expensive hence it is therefore performed
|
||
only after an L1 TLB miss. To optimise this, RMM uses a Range TLB (RTLB) to quickly identify
|
||
if an address falls within any pre-allocated range. Range mapping works alongside the paging system by generating TLB entries on
|
||
TLB misses and still performs TLB lookups for each virtual address translation.
|
||
Unlike traditional segmentation mechanisms, range mapping activates the RTLB located with the last level TLB upon a miss. The hardware TLB miss
|
||
handler then searches the RTLB for the missed address. If found, generates a new
|
||
TLB entry with the physical address derived from the base virtual address and
|
||
range offset along with the permission bits. If the RTLB also misses, the system
|
||
defaults to a standard page walk while a range table walker simultaneously
|
||
loads the range into the RTLB on the background. This avoids delays for in-memory operations.
|
||
The RTLB functions as a fully associative search structure ensuring
|
||
that most last-level TLB misses are handled efficiently by range mapping which
|
||
reduces the need for costly page table walks.
|
||
|
||
\subsection{FlexPointer}
|
||
The key insight behind FlexPointer~\cite{chen_flexpointer_2023} is that large memory objects are relatively uncommon. This allows memory ranges to be constructed around
|
||
them and assigned unique identifiers. These range IDs are embedded within the unused bits of pointers, enabling direct indexing of the range
|
||
TLB and simplifying its design. Since the range ID is unaffected by address generation, range lookups can occur earlier in the pipeline,
|
||
concurrently with address computation. Simulation results show that FlexPointer significantly reduces L1 TLB misses and the need for page walks
|
||
in a range of memory-intensive workloads. When compared with a traditional 4KB-page system, FlexPointer delivers an average performance improvement
|
||
of 14\%, with peak gains of up to 2.8×, and introduces no performance regressions in less demanding scenarios.
|
||
|
||
% Ryad comment:
|
||
% Is this from reference 12?
|
||
% Does the whole section refer to reference 12?
|
||
% The whole section is reference 12
|
||
|
||
|
||
\subsection{CHERI}
|
||
\label{sec:orgbf2eaac}
|
||
% CHERI 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
|
||
% capability architecture that can combine capabilities with conventional MMU (Memory Management Unit) based systems.
|
||
% The contributions of CHERI include:
|
||
% \begin{itemize}
|
||
% \item ISA changes to introduce architectural capabilities.
|
||
% \item New microarchitecture proving that capabilities can be implemented efficiently in hardware, with support for
|
||
% efficient tagged memory to protect capabilities and compress capabilities to reduce memory overhead.
|
||
% \item A newly designed software construction model that uses capabilities to provide fine-grained memory protection
|
||
% and scalable software compartmentalization.
|
||
% \item Language and compiler extensions for using capabilities with C and C++.
|
||
% \item OS extensions to support fine-grained memory protection (spatial, referential, and (non-stack) temporal memory safety)
|
||
% and abstraction extensions for scalable software compartmentalization.
|
||
% \end{itemize}
|
||
CHERI extends conventional processor Instruction-Set Architectures (ISAs)
|
||
with architectural capabilities to enable fine-grained memory protection
|
||
and highly scalable software compartmentalisation. It is a hybrid capability
|
||
architecture that can combine capabilities with conventional MMU (Memory Management Unit)
|
||
based systems. The contributions of CHERI includes ISA changes to introduce architectural
|
||
capabilities and is a new microarchitecture which shows that capabilities can be implemented efficiently in hardware.
|
||
CHERI provides support for efficient tagged memory to protect capabilities and compresses them to reduce memory overhead.
|
||
The CHERI ecosystem provides language and compiler extensions for using capabilities with C and C++. An OS extensions is also
|
||
provided to support fine-grained memory protection (including spatial, referential, and non-stack temporal memory safety) and abstraction extensions
|
||
for scalable software compartmentalisation.
|
||
|
||
\subsection{CHERI CC}
|
||
CHERI CC(Concentrate Compressed Capabilities)~\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI that aims to address the performance and compatibility challenges associated with
|
||
capability pointers. Capability pointers enhance memory safety by embedding bounds and permissions directly
|
||
within pointers. Traditional implementations of CHERI double their size leading in bounds to increased memory usage. CHERI CC
|
||
proposes a compression strategy that preserves security while reducing size and inefficiencies. Key contributions include a floating-point
|
||
bound encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimised space usage for larger ones.
|
||
|
||
\section{Fat Address Translations}
|
||
\label{sec:FatPointerTranslations}
|
||
Fat Address Translations (FAT) is our new memory allocator for CHERI. It uses the CHERI architecture to
|
||
bring about block-based allocations in physically contiguous memory.
|
||
FAT leverages techniques like FlexPointer~\cite{chen_flexpointer_2023}, RMM~\cite{karakostas_redundant_2015} in context of introducing
|
||
a range table to store custom address translation memory ranges to
|
||
reduce pressure on the TLB. A key component
|
||
in this implementation is the use of range addresses with CHERI CC~\cite{woodruff_cheri_2019}.
|
||
|
||
% Fat-pointer Address Translations, combined with the capabilities of the CHERI
|
||
% architecture, introduce robust memory safety and security features by incorporating additional metadata
|
||
% with memory pointers. Fat-pointer Address Translations enhanced architecture uses concepts such as FlexPointer~\cite{chen_flexpointer_2023},
|
||
% Range Memory Mapping (RMM)~\cite{karakostas_redundant_2015} to manage memory effectively.
|
||
|
||
% Range addresses play a pivotal role within the Fat Address Translations implementation, defining memory
|
||
% regions bounded by a starting address (Upper) and an ending address (Lower).
|
||
% These range addresses are encoded within FAT-pointers, allowing for precise
|
||
% control using CHERI CC~\cite{woodruff_cheri_2019} bounds over memory regions to reduce the number of TLB operations needed.
|
||
|
||
% The functionality of ranges encompasses several key aspects:
|
||
% \begin{itemize}
|
||
% \item \textbf{Creation of Physically Contiguous Memory Ranges}:
|
||
% By defining memory regions that are physically contiguous, systems can
|
||
% achieve optimal memory access patterns, enhancing performance and efficiency.
|
||
% \item \textbf{Encoding Ranges as Bounds to the Pointer}:
|
||
% 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.
|
||
% \item \textbf{Instrumenting Block-Based Allocators with Physically Contiguous Memory}:
|
||
% The integration of range-based memory concepts into memory allocation systems, such as block-based
|
||
% allocators, facilitates the efficient management and utilization of physically contiguous memory blocks,
|
||
% mitigating issues related to memory fragmentation.
|
||
% \end{itemize}
|
||
|
||
% \begin{figure}[ht]ß
|
||
% \centering
|
||
% \includesvg[width=0.8\linewidth]{diagram/drawing.svg}
|
||
% \caption{High overview architecture}
|
||
% \label{fig:HighOverviewArchitecture}√
|
||
% \end{figure}
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[width=0.8\linewidth]{diagram/drawing.pdf}
|
||
\caption{High overview architecture}
|
||
\label{fig:HighOverviewArchitecture}
|
||
\end{figure}
|
||
|
||
% \begin{figure}[h]
|
||
% \includegraphics[width=0.5\textwidth]{diagram/drawing_png.png}
|
||
% \caption{High overview architecture}
|
||
% \label{fig:HighOverviewArchitecture}
|
||
% % \end{minipage}
|
||
% \end{figure}
|
||
|
||
% Figure \ref{fig:HighOverviewArchitecture} illustrates a high overview of the FAT allocator. The rectangular rectangle represents
|
||
% addresses in memory and the box from v1 to v100 represents a physically contiguous region of memory. The physically contiguous region of
|
||
% memory is normally allocated using huge pages. When malloc is called the Capability pointer is returned with meta data related to the bounds
|
||
% information encoded in the pointer. The bounds encoded in the pointer is reused for tracking memory blocks within a huge page. As shown this in
|
||
% turn reduces the TLB pressure.
|
||
|
||
Figure \ref{fig:HighOverviewArchitecture} illustrates a high-level overview of the FAT allocator. The dotted rectangular box represents
|
||
addresses in memory, and the box from v1 to v100 represents a physically contiguous region of memory. This physically contiguous
|
||
region is typically allocated using huge pages. When malloc is called, a capability pointer is returned with metadata related to
|
||
the bounds information encoded within the pointer. The bounds encoded in the pointer are reused for tracking memory blocks within a
|
||
huge page. As shown, this in turn reduces TLB pressure.
|
||
|
||
% comparison between standard memory allocation (\textit{malloc}) and the proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit
|
||
% virtual addresses and the TLB hierarchy (L1, L2 and L3 cache) to achieve non-contiguous allocation in physical memory.
|
||
% This typically results in more TLB entries and increased TLB misses increasing the reasoning to have more TLB walks.
|
||
% In contrast, the FAT method employs a custom allocator leveraging
|
||
% physically contiguous memory by using CHERI to encode
|
||
% bounds within the pointers and as shown in the figure \ref{fig:HighOverviewArchitecture}. There is almost no reliance on walking the TLB hierarchy.
|
||
|
||
% Figure \ref{fig:HighOverviewArchitecture} illustrates
|
||
% the methodology employed to use 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 approach.
|
||
|
||
% We explore how using huge pages
|
||
% with CHERI bounds can reduce the
|
||
% number of TLB entries required.
|
||
|
||
\subsection{Encoding Ranges as Bounds to the Pointer}
|
||
% \label{sec:RangeMemory}
|
||
% \begin{figure}[h]
|
||
% \includegraphics[width=0.4\textwidth]{diagram/AllocationOverview24.png}
|
||
% \caption{Range of memory}
|
||
% \label{fig:RangeOfMemory}
|
||
% \end{figure}
|
||
% Integrating range bounds directly into FAT-pointers enables the CHERI architecture
|
||
% to enforce memory access restrictions at the pointer level thus allowing
|
||
% tracking of memory ranges on a pointer level.
|
||
Range is defined from work based on RMM~\cite{karakostas_redundant_2015} and FlexPointer~\cite{chen_flexpointer_2023}. In RMM a range refers to a contiguous region of memory
|
||
defined by a base address and a bound. This information is stored in a hardware managed table called Range Table
|
||
which is called when there is a L1 TLB miss. FlexPointer builds up on the work of RMM and stores the ID value between 48th bit
|
||
and 64th bit which is the value to check the range table on parallel to the L1 TLB lookup.
|
||
|
||
The FAT allocator builds up on the concept of range from RMM and FlexPointer. Instead of using a
|
||
hardware range table using CHERI range information can be encoded within a capability pointer.
|
||
A memory range in FAT has two points to track memory in physically contiguous space which
|
||
is the top and bottom. These two points are two virtual addresses and the range consists of
|
||
addresses that lie within this and refers to addresses allocated by invoking \textit{malloc}.
|
||
FAT memory ranges are established using
|
||
bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019} compression scheme.
|
||
% as referred in section ~\ref{sec:128bitCompressedBounds}.
|
||
|
||
% Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single
|
||
% large contiguous memory area or huge page. Within this huge page the orange and blue lines indicate
|
||
% two separate memory allocations equivalent to invoking \textit{malloc} twice to allocate memory in distinct regions.
|
||
% This scenario simulates a block-based memory allocator operating within the confines of a huge page.
|
||
% The allocations use the bounds encoded in FAT which ensures tracking of the allocated memory regions.
|
||
% By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page.
|
||
|
||
\section{128 bit compressed bounds}
|
||
\label{sec:128bitCompressedBounds}
|
||
% We use CHERI CC (Compressed bounds) to track regions of memory used in physically
|
||
% contigous space. CHERI CC consists of bounds which are compressed and represent a
|
||
% 128 bit pointer with a 64 bit virtual address system. Our appproach is to use
|
||
% a constant single cycle to encode and decode bounds. CHERI CC was originally intended
|
||
% for memory protection but can also be repurposed for tracking memory region rather
|
||
% than using the standard approach with consists of numerous TLB entries for each allocation.
|
||
|
||
% One of the key analysis highlighted by CHERI CC is that allocators such as Jemalloc always
|
||
% allocate objects under 512 bytes. When a bound of an object cannot be represented it is required
|
||
% to be padded to memory. It was noted that allocators just as Jemalloc in practice do not require
|
||
% more than 6 bits to represent exponents needed within the compressed bounds.
|
||
|
||
% This means the default behavoir of most allocators such as Jemalloc would precisely represent bounds
|
||
% within the FAT-Pointer which can be repurposed as ranges in memory allocators with custom allocation
|
||
% sizes rather than fixed sized TLB entries.
|
||
|
||
FAT uses CHERI CC~\cite{woodruff_cheri_2019} to track regions of memory in physically contiguous space.
|
||
CHERI CC consists of compressed bounds that represent a 128-bit pointer within a 64-bit virtual address
|
||
system. Our approach uses the work of CHERI CC by using a single cycle to decode bounds from the
|
||
capability register and the bounds that are decoded are repurposed for tracking memory which is eagerly
|
||
allocated.
|
||
% Our approach utilizes a single-cycle encoding and decoding mechanism for efficiency. While CHERI
|
||
% CC was originally designed for memory protection, it can also be repurposed for tracking memory regions,
|
||
% eliminating the need for multiple TLB entries for each allocation.
|
||
|
||
Allocators like Jemalloc typically allocate objects under
|
||
512 bytes. When an object's bounds cannot be precisely represented, padding is required to ensure
|
||
memory safety. However, it has been observed that Jemalloc rarely needs more than 6 bits to store the
|
||
exponent values within compressed bounds (as shown in~\cite{woodruff_cheri_2019}). This means that the default behavior of allocators such as Jemalloc, would allow precise
|
||
representation of bounds within CHERI CC.
|
||
|
||
% With FAT rather than using fixed size TLB entries page sizes (such as 4KB, 2MB and 1GB pages)
|
||
% we use CHERI CC bounds to be dynamic in size to be defined based on the size provided when calling
|
||
% malloc offering a more flexible alternative than fixed-size TLB entries.
|
||
|
||
Instead of relying on fixed-size TLB entries with set page sizes (such as 4KB, 2MB, or 1GB), FAT uses CHERI
|
||
CC to define dynamic bounds based on the size requested at allocation time (e.g., during a \textit{malloc} call).
|
||
This approach offers flexible translation entry sizes compared to the traditional fixed-size TLB model.
|
||
|
||
This means that the default behavior of most allocators, such
|
||
as Jemalloc, would allow precise representation of bounds within
|
||
a FAT. These pointers can then be repurposed as memory ranges in custom memory allocators, offering a more flexible
|
||
alternative to fixed-size TLB entries.
|
||
|
||
% We use the CHERI CC
|
||
% bounds to be repurposed to encode dynamic sized addresses ranges.
|
||
% These pointers can then be repurposed as memory ranges
|
||
% in custom memory allocators, offering a more flexible alternative to fixed-size TLB entries.
|
||
|
||
% \subsection{Creation of Physically Contiguous Memory Ranges}
|
||
|
||
% \smallskip\noindent
|
||
% The memory chunk defined by the upper and lower bounds is always physically contiguous.
|
||
% By defining memory regions that are physically contiguous, systems can
|
||
% achieve optimal memory access patterns, enhancing performance and efficiency.
|
||
|
||
\subsection{Instrumenting Block-Based Allocators with Physically Contiguous Memory}
|
||
% \begin{figure}[h]
|
||
% \includegraphics[width=0.4\textwidth]{diagram/TLBAccess.drawio.png}
|
||
% \caption{FAT Address Translations using huge pages}
|
||
% \label{fig:HugePages}
|
||
% \end{figure}
|
||
% To build up based on Section ~\ref{sec:RangeMemory} and ~\ref{sec:128bitCompressedBounds}.
|
||
FAT is able to pre-allocate memory using huge pages and is able to mark smaller allocations
|
||
using ranges by storing them as bounds within the pointer. Each of these memory ranges can be
|
||
called a block. Since there are numerous blocks inside a huge page, This allows for abbreviated block-based
|
||
memory patterns within physically contiguous memory.
|
||
|
||
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
|
||
to track and access memory within physically contiguous memory.
|
||
|
||
% As demonstrated with the allocator
|
||
% implementation in section ~\ref{sec:MemoryAllocator}.
|
||
|
||
%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~\cite{TLBBehavoir}. In contrast, FAT
|
||
%simplifies this by using a single TLB
|
||
%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,
|
||
%the FAT 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.
|
||
% This streamlined (TODO)
|
||
% 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:HugePages} illustrates a use-case of huge pages where the green
|
||
% line represents sample access to read within a contiguous
|
||
% space of physical memory. The dotted lines represent the
|
||
% bounds for that particular pointer access. Using bounds
|
||
% stored on the pointer a block-based pattern can be replicated
|
||
% on physically contiguous memory.
|
||
|
||
\section{Memory allocator design}
|
||
\label{sec:MemoryAllocator}
|
||
This section presents a memory allocator design which is implemented based on the
|
||
principles outlined in FAT (Section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: \textit{InitAlloc},
|
||
\textit{malloc}, and \textit{free}. The \textit{InitAlloc} function initialises the memory pool, setting up the necessary
|
||
data structures and metadata required for efficient memory management. The \textit{malloc} function is
|
||
responsible for allocating a contiguous block of memory of a specified size. When the \textit{free}
|
||
function deallocates memory it is returned 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. 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 with significantly lesser L1 TLB misses with programs with heavy memory usage with smaller allocations where physical memory
|
||
% contiguity is essential.
|
||
|
||
\begin{algorithm}
|
||
\caption{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}
|
||
\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 \textit{malloc} function (Algorithm \ref{alg:malloc}) is invoked, the algorithm employs an eager allocation strategy for physical memory.
|
||
This is achieved through the use of the SetBounds mechanism. This constructs a FAT-specialised
|
||
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 \textit{malloc}. This
|
||
approach introduces a method of memory tracking, where the bounds of the allocated region is
|
||
explicitly encoded in the address which enables efficient monitoring and management of memory usage.
|
||
|
||
Furthermore, this design uses huge page TLB 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 reducing the risk of out-of-bounds
|
||
errors. This use of FAT and shared TLB entries not only align with the principles of
|
||
efficient memory management but also demonstrate a practical use case of huge pages in CHERI.
|
||
|
||
\begin{algorithm}
|
||
\caption{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}
|
||
\State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
|
||
\EndFunction
|
||
\end{algorithmic}
|
||
\end{algorithm}
|
||
|
||
The memory deallocation (Algorithm \ref{alg:free}) mechanism in the proposed allocator is facilitated by the FAT structure
|
||
introduced in the \textit{malloc} algorithm. When the \textit{free} function is invoked, it uses the metadata
|
||
embedded within FAT to determine the range and size of the allocated memory region.
|
||
Specifically, FAT encodes the start and end addresses of each allocation and provides the information needed to
|
||
identify the memory block to be deallocated. This enables the allocator to accurately unmap the corresponding
|
||
memory region from the address space.
|
||
|
||
% Specifically, the start and end addresses encoded in FAT to provide the necessary information
|
||
% to identify the exact memory block to be deallocated. This allows the allocator to unmap
|
||
% the corresponding memory region from the address space.
|
||
|
||
By extracting the bounds and size directly from FAT, the \textit{free} function eliminates the need
|
||
for additional metadata lookups or complex data structures.
|
||
% , streamlining the deallocation process.
|
||
% This approach not only enhances performance but also reduces the risk of memory leaks or fragmentation.
|
||
|
||
|
||
|
||
\begin{algorithm}
|
||
\caption{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}
|
||
\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}
|
||
|
||
Algorithm \ref{alg:initAlloc} describes the initialisation of physically contiguous memory through the use of huge pages
|
||
which is a mechanism supported by modern architectures to optimise memory management. The algorithm begins by
|
||
allocating a fixed block of 1 GB 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 which is critical for performance-sensitive
|
||
applications and kernel-level operations.
|
||
|
||
\section{Embedding FAT allocator inside Jemalloc}
|
||
\label{sec:JemallocFATAllocator}
|
||
This section describes the FAT allocator implementation (Section \ref{sec:MemoryAllocator}) embedded inside Jemalloc. The objective here is to describe the changes needed
|
||
for a block based allocator to use physically contigous memory with a block based strategy with the help of capability based addresses.
|
||
In the case of Jemalloc the only changes required was to replace the mmap with the \textit{malloc} function (Algorithm \ref{alg:malloc}) and
|
||
for munmap the \textit{free} function (Algorithm \ref{alg:free}).
|
||
|
||
\begin{algorithm}
|
||
\caption{Modified Jemalloc Memory Mapping Routines}
|
||
\label{alg:JemallocMalloc}
|
||
\begin{algorithmic}[1]
|
||
|
||
\Statex \textbf{Function:} \textsc{os\_pages\_map(addr, size, alignment, commit)}
|
||
\Require addr aligned to \texttt{os\_page}, size aligned to \texttt{os\_page}, size $\neq 0$
|
||
\Ensure If \texttt{addr} is non-NULL (CheriABI), return NULL
|
||
|
||
\If{$\text{addr} \neq \text{NULL}$}
|
||
\State \Return NULL
|
||
\EndIf
|
||
|
||
\If{os\_overcommits}
|
||
\State commit $\gets$ true
|
||
\EndIf
|
||
|
||
\State ret $\gets$ \textbf{MALLOC}(size)
|
||
\State \textbf{assert}(ret $\neq$ NULL)
|
||
|
||
\If{addr $\neq$ NULL \textbf{and} ret $\neq$ addr}
|
||
\State \texttt{os\_pages\_unmap}(ret, size)
|
||
\State ret $\gets$ NULL
|
||
\EndIf
|
||
|
||
\State \Return ret
|
||
|
||
\vspace{1em}
|
||
\Statex \textbf{Function:} \textsc{pages\_map(addr, size, alignment, commit)}
|
||
\Require alignment $\geq$ \texttt{PAGE}, addr aligned to alignment
|
||
|
||
\State ret $\gets$ \textbf{MALLOC}(size)
|
||
|
||
\State \Return ret
|
||
|
||
\vspace{1em}
|
||
\Statex \textbf{Function:} \textsc{pages\_commit\_impl(addr, size, commit)}
|
||
\Require addr aligned to \texttt{PAGE}, size aligned to \texttt{PAGE}
|
||
|
||
\State result $\gets$ \textbf{MALLOC}(size)
|
||
|
||
\If{result $\neq$ addr}
|
||
\State \texttt{os\_pages\_unmap}(result, size)
|
||
\State \Return true
|
||
\EndIf
|
||
|
||
\State \Return false
|
||
|
||
\end{algorithmic}
|
||
\end{algorithm}
|
||
|
||
\subsection{Mmap replaced with MALLOC}
|
||
|
||
The os\_pages\_map function (Algorithm~\ref{alg:JemallocMalloc}) simulates Jemalloc's low-level page
|
||
mapping routine. It first checks if a specific address is
|
||
requested in case relevant to CheriABI~\cite{CheriABI} where such behavior
|
||
is disallowed and returns NULL. It then allocates memory using the custom MALLOC(size) (Algorithm~\ref{alg:malloc}) function and validates
|
||
whether the returned pointer matches the requested address
|
||
if one was provided. If there's a mismatch, it unmaps calling FREE() (Algorithm~\ref{alg:free}) the
|
||
memory and returns NULL; otherwise, it returns the allocated
|
||
pointer.
|
||
|
||
This approach mentioned above is embedded inside Jemalloc's strategy of managing memory through arenas~\cite{jemalloc} and size~\cite{jemalloc} classes.
|
||
In Jemalloc, memory is divided into chunks, which are further subdivided into runs and regions to
|
||
handle allocations of various sizes efficiently. By aligning sizes and managing allocations within
|
||
predefined structures, Jemalloc minimizes fragmentation~\cite{evans_scalable_nodate}.
|
||
|
||
% The only function required to be replaced with Malloc was os\_pages\_map,
|
||
% pages\_map and pages\_commit\_impl as show in
|
||
% algorithm \ref{alg:JemallocMalloc}.
|
||
|
||
\begin{algorithm}
|
||
\caption{os\_pages\_unmap}
|
||
\label{alg:JemallocFree}
|
||
\begin{algorithmic}[1]
|
||
\Require addr aligned to \texttt{os\_page}, size aligned to \texttt{os\_page}
|
||
\Ensure Memory region at \texttt{addr} is unmapped
|
||
\State \textbf{assert}(\texttt{ALIGNMENT\_ADDR2BASE}(addr, os\_page) $=$ \texttt{addr})
|
||
\State \textbf{assert}(\texttt{ALIGNMENT\_CEILING}(size, os\_page) $=$ size)
|
||
|
||
\State \textbf{FREE}(addr)
|
||
\end{algorithmic}
|
||
\end{algorithm}
|
||
|
||
\subsection{Munmap replaced with FREE}
|
||
|
||
The os\_pages\_unmap (Algorithm~\ref{alg:JemallocFree}) represents a customized abstraction of Jemallocs
|
||
memory unmapping routine, designed to integrate with the previously defined simplified
|
||
free(ptr) implementation. In conventional Jemalloc configurations, os\_pages\_unmap would
|
||
invoke low-level system calls such as munmap to release virtual memory pages back to the
|
||
operating system. However, in this adapted version, the function instead delegates the
|
||
deallocation to a higher-level FREE(addr) (Algorithm~\ref{alg:free}).
|
||
|
||
The function begins by enforcing two invariants through assertions: first, that the input
|
||
address addr is aligned to the operating system's page size and second that
|
||
the size of the memory region is also a multiple of os\_page. These alignment checks are
|
||
critical for maintaining consistency with Jemalloc's internal page-based memory
|
||
management semantics and ensuring compatibility with the allocator's expectations.
|
||
Following these checks the memory at the specified address is deallocated via the
|
||
FREE(addr) (Algorithm~\ref{alg:free}) operation.
|
||
|
||
The following changes done to free is embedded inside Jemalloc's deallocation mechanism,
|
||
where metadata associated with each allocation
|
||
(such as size and location) is used to efficiently return memory to the appropriate
|
||
arena or pool. Jemalloc maintains
|
||
separate metadata structures to track allocations, allowing for quick deallocation and
|
||
reuse of memory blocks
|
||
without significant overhead~\cite{evans_scalable_nodate}.
|
||
|
||
% The only function required to be replaced with Free was
|
||
% os\_pages\_unmap as show in
|
||
% algorithm \ref{alg:JemallocFree}.
|
||
|
||
\section{Evaluation}
|
||
\label{sec:Evaluation}
|
||
Benchmarks of the FAT memory allocator and the FAT allocator embedded within Jemalloc against the standard Jemalloc~\cite{jemalloc} allocator was conducted.
|
||
Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}. The objective was to evaluate
|
||
the reduction of TLB walks and misses and its impact on the wall clock runtime.
|
||
|
||
To comprehensively analyse the implemented allocator, the benchmarks~\cite{Benchmark} were categorised into
|
||
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
|
||
C programs designed to target specific allocator patterns such as the memory read operations which enables us to evaluate
|
||
detailed aspects of the allocators behavior. Macro benchmarks, on the other hand,
|
||
encompass larger real-world C programs allowing us to assess the allocators
|
||
performance in a more practical and real-world scenarios.
|
||
|
||
% The experiment setup (section~\ref{sec:Experiment}) details the software stack used for evaluation. It includes
|
||
% the specific configurations, compiler options, and system environment tailored
|
||
% to benchmark the proposed allocator. This ensures consistency and repeatability
|
||
% in our results, providing a solid foundation for meaningful comparisons.
|
||
|
||
% We further elaborated on the two classes of benchmarks executed. Micro benchmarks (section~\ref{sec:Micro}).
|
||
% focused on particular allocation and deallocation patterns, such as sequential and
|
||
% random memory accesses, to stress-test the allocator under controlled conditions.
|
||
% Macro benchmarks (section~\ref{sec:Macro}) involved real-world applications, offering insights into how
|
||
% the allocator performs with complex memory allocation demands, large datasets,
|
||
% and varying execution contexts.
|
||
|
||
% The results (section~\ref{sec:Results}) presents the outcomes of our benchmarks, highlighting key metrics
|
||
% such as TLB miss rates, memory usage, and runtime performance. We observed that the
|
||
% proposed allocator demonstrated significant improvements in reducing TLB misses,
|
||
% leading to noticeable enhancements in runtime efficiency for both micro and macro
|
||
% benchmarks. The behavior of specific allocation patterns and their impact on memory
|
||
% performance is detailed, providing a nuanced understanding of the allocator's effectiveness.
|
||
|
||
%Based on the evaluated results (section~\cite{sec:Usability}), the usability of the proposed allocator shows promise
|
||
%for applications requiring optimized memory management and reduced overhead from TLB misses.
|
||
%However, limitations were also identified, such as scenarios where the allocator's performance
|
||
%gains were marginal or where it introduced additional complexity in memory management.
|
||
|
||
\subsection{Experiment setup}
|
||
\label{sec:Experiment}
|
||
The CHERI Morello~\cite{Morello} board was used to evaluate the proposed memory allocator.
|
||
Morello implements the ARMv8 with enhanced server-class memory, featuring a
|
||
quad-core ARM CPU with capability extensions. The L1 and L2 caches were modified
|
||
to proliferate the capability bit which ensures compatibility with CHERI's capability-based
|
||
memory model. When compiling the C programs for benchmarking, the Benchmark ABI~\cite{BenchmarkABI} was
|
||
used as recommended by the CHERI community. This compilation mode was enabled using
|
||
the Clang compiler.
|
||
|
||
The Benchmark ABI was specifically designed because the Morello branch predictor
|
||
was not expanded to predict bounds. Consequently, a capability-based jump introduces
|
||
stalls in later PCC-dependent(Program Counter Capability) instructions until bounds are established. This issue
|
||
is particularly significant during dynamically linked calls and returns between
|
||
libraries where bounds are changed to cover the called or returned-to library.
|
||
Such stalls can negatively affect performance, making the Benchmark ABI an essential
|
||
consideration for this evaluation.
|
||
|
||
Each C program was executed using two different memory allocators. The first was
|
||
the FAT allocator(Section ~\ref{sec:MemoryAllocator}) which is imported as a header file. This approach was necessary
|
||
because the Benchmark ABI shared object file exhibited unexpected behavior by
|
||
failing to overwrite the C program at runtime with the intended \textit{malloc} functions.
|
||
The second allocator was the standard OS memory allocator, which in the case of
|
||
CHERIBSD is Jemalloc.
|
||
|
||
Performance measurements (table ~\ref{table:ARMPerf}) were carried out using ARM hardware performance counters~\cite{PerformanceCounter} to
|
||
ensure accurate evaluation. These counters provided detailed metrics allowing
|
||
us to compare the performance of the two allocators and assess the impact of
|
||
the proposed changes.
|
||
|
||
\begin{table*}[b]
|
||
\caption{\label{tab:org246a883}ARM performance counters}
|
||
\centering
|
||
\begin{tabular}{|l|l|}
|
||
\hline
|
||
Performance counter & Description \\
|
||
\hline
|
||
Wall clock & The actual time taken from the start of a \\
|
||
& computer program to the end. \\
|
||
& \\
|
||
(p/l1d\_tlb\_rd) L1 data TLB reads & Level 1 data TLB access, read \\
|
||
& \\
|
||
(p/l2d\_tlb\_rd) L2 data TLB reads & Level 2 data TLB access, read \\
|
||
& \\
|
||
(p/l1d\_tlb\_refill) L1 data TLB refills & Level 1 data TLB refill. \\
|
||
& The Level 1 data TLB refill \\
|
||
& counter tracks each access to \\
|
||
& the L1D\_TLB that results \\
|
||
& in a refill of the Level 1 data \\
|
||
& or unified TLB. This includes any \\
|
||
& access that requires a memory lookup \\
|
||
& due to a translation table walk \\
|
||
& or accessing another level of TLB cache. \\
|
||
& \\
|
||
(p/dtlb\_walk) Data TLB walks & Data TLB access with at least \\
|
||
& one translation table walk. \\
|
||
& \\
|
||
(p/ll\_cache\_miss\_rd) Last level cache miss reads & Last level cache miss, read \\
|
||
& (This refers to every miss in the \\
|
||
& Last level cache that occurs \\
|
||
& during a memory read operation.) \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{table:ARMPerf}
|
||
\end{table*}
|
||
|
||
\subsection{Benchmarks}
|
||
Elaborated here are two classes of benchmarks. Micro benchmarks
|
||
focus on particular allocation, deallocation patterns such as sequential and
|
||
random memory accesses. This is to stress-test the allocator under controlled conditions.
|
||
Macro benchmarks involves real-world applications offering insights into how
|
||
the allocator performs with complex memory allocation demands such as large datasets with varying execution contexts.
|
||
|
||
\subsubsection{Micro benchmark}
|
||
\label{sec:Micro}
|
||
|
||
\begin{itemize}
|
||
\item \texttt{GLIBC}: The Glibc benchmark evaluates the performance of
|
||
\textit{malloc} and \textit{free} functions in single-threaded, multi-threaded,
|
||
and emulated multi-threading scenarios using various block sizes
|
||
allocation patterns. It simulates real-world memory usage by partially
|
||
deallocating blocks in FIFO order and fully deallocating them in LIFO order.
|
||
Results are gathered across configurations to analyse performance variations.
|
||
\item \texttt{MemAccess}: This benchmark evaluates the performance impact of
|
||
memory access patterns by constructing and traversing a doubly
|
||
linked list with varying working set sizes. It supports sequential or
|
||
randomised structures with optional node operations and multithreaded
|
||
traversal using pthreads. The program dynamically allocates memory and systematically
|
||
doubles the working set size to analyse memory hierarchy behavior.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Macro benchmark}
|
||
\label{sec:Macro}
|
||
|
||
\begin{itemize}
|
||
\item \texttt{Kmeans}: Kmeans implements a parallelised K-means clustering algorithm that
|
||
assigns data points to clusters based on proximity to the centroids.
|
||
This iteratively updates them until convergence. The computation is
|
||
distributed across threads using the pthread library, dynamically
|
||
assigning tasks to optimise performance. Parameters like data size
|
||
and clusters are configurable and the program ensures efficient
|
||
memory management and synchronisation.
|
||
\item \texttt{Richards}: Richards is a task scheduling benchmark that simulates a
|
||
multitasking environment with tasks of varying types and priorities which is
|
||
communicated through queued packets. The schedule function manages
|
||
task execution based on the state, priority and tracks processed packets
|
||
which are held tasks for performance evaluation. Configurable iterations and
|
||
timing help measure system performance to ensure correctness.
|
||
\item \texttt{BARNES}: Implements the Barnes-Hut algorithm to efficiently simulate the interactions within
|
||
an \(N\)-body system. A comprehensive overview of the Barnes-Hut method is provided by Singh in his doctoral
|
||
dissertation ~\cite{singh1993}. This implementation extends the original method by permitting multiple
|
||
particles to be stored within each leaf cell of the spatial decomposition, enhancing performance and scalability.
|
||
This extension is described by Holt and Singh ~\cite{holt1995}.
|
||
\end{itemize}
|
||
|
||
|
||
\subsection{Results and discussion}
|
||
\label{sec:Results}
|
||
|
||
% \begin{figure}[b]
|
||
% \centering
|
||
% \begin{subfigure}{.5\textwidth}
|
||
% \centering
|
||
% \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \end{subfigure}%
|
||
% \begin{subfigure}{.5\textwidth}
|
||
% \centering
|
||
% \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \end{subfigure}
|
||
% \begin{subfigure}{.5\textwidth}
|
||
% \centering
|
||
% \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \end{subfigure}%
|
||
% \begin{subfigure}{.5\textwidth}
|
||
% \centering
|
||
% \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \end{subfigure}
|
||
% \begin{subfigure}{\textwidth}
|
||
% \raggedleft
|
||
% \includegraphics[width=0.45\textwidth]{IMAGE NAME}
|
||
% \end{subfigure}
|
||
% \caption[short]{A beautiful, well written caption}
|
||
% \end{figure}
|
||
|
||
% \begin{figure*}
|
||
% \begin{multicols}{2}
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}\par
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l1tlb-reads.png}\par
|
||
% \end{multicols}
|
||
% \begin{multicols}{2}
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l1tlb-refill.png}\par
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l2tlb-reads.png}\par
|
||
% \end{multicols}
|
||
% \begin{multicols}{2}
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-ll-cache-rd.png}\par
|
||
% \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-wallclock.png}\par
|
||
% \end{multicols}
|
||
% \caption{Benchmarks comparing the percentage difference between FAT }
|
||
% \end{figure*}
|
||
|
||
\begin{figure*}
|
||
\begin{multicols}{2}
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-l1_tlb_rd.png}
|
||
\caption{L1 TLB Reads}
|
||
\label{fig:l1tlb-reads}
|
||
\end{subfigure}\par
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-l2_tlb_rd.png}
|
||
\caption{L2 TLB Reads}
|
||
\label{fig:l2tlb-reads}
|
||
\end{subfigure}\par
|
||
\end{multicols}
|
||
|
||
\begin{multicols}{2}
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-dtlb_walk.png}
|
||
\caption{DTLB Walks}
|
||
\label{fig:dtlb-walk}
|
||
\end{subfigure}\par
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-l1tlb_refill.png}
|
||
\caption{L1 DTLB Refill}
|
||
\label{fig:l1tlb-refill}
|
||
\end{subfigure}\par
|
||
\end{multicols}
|
||
|
||
\begin{multicols}{2}
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-last-cache-miss-read.png}
|
||
\caption{LL Cache Reads}
|
||
\label{fig:ll-cache-rd}
|
||
\end{subfigure}\par
|
||
\begin{subfigure}{\linewidth}
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/large/bargraph-large-wallclock.png}
|
||
\caption{Wall Clock Time}
|
||
\label{fig:wallclock}
|
||
\end{subfigure}\par
|
||
\end{multicols}
|
||
|
||
\caption{Benchmarks comparing the percentage difference between FAT.}
|
||
\label{fig:benchmarks-group}
|
||
\end{figure*}
|
||
|
||
% \begin{figure*}[h]
|
||
% \includegraphics[width=.9\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \caption{\label{fig:bargraph}Percentage difference between the modified memory allocator against the default system memory allocator}
|
||
% \end{figure*}
|
||
% \begin{figure*}[h]
|
||
% \includegraphics[width=.9\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
|
||
% \caption{\label{fig:bargrapwh}Percentage difference between the modified memory allocator against the default system memory allocator}
|
||
% \end{figure*}
|
||
|
||
Figure~\ref{fig:benchmarks-group} highlights the performance comparison between the modified memory allocator and
|
||
Jemalloc, the default memory allocator. The FAT memory allocator is specifically optimised
|
||
for use with huge pages and demonstrates a clear advantage in scenarios where memory allocation
|
||
patterns benefit from its design. The results align with expectations, showcasing the impact
|
||
of its capability to handle memory more efficiently by leveraging huge pages.
|
||
|
||
\begin{itemize}
|
||
% \item L1 DTLB reads: L1 Data TLB reads are critical for achieving fast memory access, and a reduction
|
||
% in events that could signify misses or lead to further lookups is generally beneficial. FAT allocator consistently performed
|
||
% at the baseline level (100\%) across all benchmarks including Kmeans, Memaccess, Glibc, Richards, and Barnes.
|
||
% In contrast, FAT allocator embedded inside Jemalloc exhibited varied performance. It achieved a notable 14\%
|
||
% reduction in L1D TLB reads for Kmeans and a minor 3\% reduction for Barnes. More significantly, it
|
||
% led to a substantial 68\% reduction for Memaccess, a benchmark characterized by linked list traversals
|
||
% that can challenge memory access efficiency, and a 59\% reduction for Glibc, which involves numerous memory
|
||
% allocation and deallocation operations. For the Richards benchmark, however, no significant change was observed with
|
||
% FAT allocator embedded inside Jemalloc. These results suggest that FAT allocator embedded inside Jemalloc may arrange memory
|
||
% in a manner that enhances spatial locality at the page level, particularly for workloads like Memaccess and Glibc.
|
||
|
||
\item L1 TLB reads (Figure~\ref{fig:l1tlb-reads}): L1 TLB reads are critical for achieving fast memory access; therefore, a
|
||
reduction in events that could signify misses or lead to further lookups is generally beneficial.
|
||
In the Kmeans benchmark, the FAT allocator demonstrated 13\% fewer L1 TLB reads than the baseline allocator.
|
||
However, when the FAT allocator was embedded within Jemalloc, the L1 TLB reads were the same as the baseline.
|
||
For the memaccess benchmark, the embedded FAT allocator resulted in 68\% fewer L1 TLB reads compared to the baseline
|
||
allocator. A similar pattern was observed with Glibc, showing 59\% fewer L1 TLB reads. In the Richards benchmark,
|
||
there was no difference for either allocator. For the Barnes benchmark, the FAT allocator exhibited 5\%
|
||
fewer L1 TLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.
|
||
|
||
\item L2 TLB reads (Figure~\ref{fig:l2tlb-reads}): L2 Data TLB reads (or lookups) serve as a secondary cache for address translations.
|
||
FAT allocator consistently performed at 98\% lesser L2 TLB reads for this metric across all benchmarks except Barnes
|
||
which was 4\% lesser. FAT allocator embedded inside Jemalloc also showed significant change for Kmeans, Memaccess, and Richards. However, for the Glibc benchmark
|
||
it achieved a reduction of 60\% in L2 TLB reads. This mirrors its L1D TLB improvement for Glibc and suggests that its
|
||
strategy for page locality extends effectively to deeper levels of the TLB hierarchy for this particular benchmark, which is notable given
|
||
Glibc's high frequency of malloc calls that stress memory management. A minor reduction of 5 \% was also observed for the Barnes
|
||
benchmark with FAT allocator embedded inside Jemalloc.
|
||
|
||
\item DTLB walks (Figure~\ref{fig:dtlb-walk}): which occur when a virtual-to-physical
|
||
address translation is not found in the DTLB and a page table traversal is necessary, represent a performance
|
||
cost. thus, fewer walks are preferable. In the observed tests neither FAT allocator nor FAT allocator embedded inside Jemalloc
|
||
demonstrated significant deviation from the baseline performance of 99\% lesser walks.
|
||
This consistent behavior was noted across all benchmarks evaluated: Kmeans, Memaccess, Glibc, Richards, and Barnes.
|
||
This indicates that almost all address translations were resolved directly at the L1 DTLB level
|
||
without triggering expensive traversals through the page table. More generally, this finding
|
||
demonstrates that both allocator designs make efficient use of the hardware translation system and
|
||
maintain consistently low page walk overheads across a range of workloads.
|
||
|
||
% This outcome suggests that most translations were done at the L1 DTLB level.
|
||
|
||
% the memory allocation strategies employed by these allocators do substantially alter the frequency
|
||
% of DTLB misses that necessitate page table walks within these specific workloads. Even for the Memaccess benchmark,
|
||
% which is designed with random list traversals that can stress TLB pressure, the impact on dTLB walks was negligible according to the provided graphs.
|
||
|
||
\item L1 TLB refills (Figure~\ref{fig:l1tlb-refill}): L1 Data TLB refills are a direct consequence of L1 TLB misses; therefore, fewer refills
|
||
indicate better performance. Interestingly, despite the variations observed in L1 TLB reads for the FAT allocator
|
||
embedded within Jemalloc, the L1 TLB refills metric showed a significant reduction of 99\% for both the standalone
|
||
FAT allocator and the FAT allocator embedded within Jemalloc. This consistent and substantial improvement over the baseline was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes.
|
||
|
||
% L1 Data TLB refills are a direct consequence of L1D TLB misses, with fewer refills indicating better performance.
|
||
% Interestingly, despite the variations observed in L1D TLB reads for FAT allocator embedded inside Jemalloc, the L1D TLB refills metric
|
||
% resulted at a significant reduction of 99\% lesser for both FAT allocator and FAT allocator embedded inside Jemalloc. This consistent performance at baseline
|
||
% was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes.
|
||
% The absence of change in refills might suggest that the "reads" metric captures a wider range of TLB interaction
|
||
% events than solely those leading to refills, or perhaps the absolute number of critical misses resulting in refills was minimal to begin with and thus
|
||
% not significantly affected by the allocators in these tests.
|
||
|
||
\item Last-level cache (Figure~\ref{fig:ll-cache-rd}): Cache read misses in the Last-Level Cache (LLC) are critical performance indicators, as they typically lead to
|
||
slower data retrievals from main memory. Consequently, a lower number of misses is highly desirable. The performance on this
|
||
metric varied considerably across both allocators and benchmarks. The FAT allocator exhibited the highest variance in the
|
||
kmeans benchmark, achieving 57\% fewer cache misses compared to the baseline allocator. In contrast, it recorded 18\% more
|
||
misses in memaccess, 65\% fewer in glibc, 31\% more in Richards, and 18\% more in barnes.
|
||
When the FAT allocator was embedded within Jemalloc, the results shifted notably: kmeans experienced 19\% more misses
|
||
relative to the baseline, memaccess saw a substantial 77\% reduction, while glibc incurred a dramatic 370\% increase particularly
|
||
significant given its malloc intensive nature. There was no change in LLC misses for Richards, whereas barnes suffered from 68\%
|
||
more misses.
|
||
|
||
|
||
% Last-Level Cache read misses are crucial performance indicators, as they often result in slow data fetches
|
||
% from main memory therefore fewer misses are highly desirable. The performance on this metric varied significantly between the
|
||
% allocators and across benchmarks. FAT allocator had a highest variance for kmeans with 57\% lesser cache misses than than the
|
||
% baseline allocator, memaccess with 18\% more, Glibc with 65\% less, Richards with 31\% more and barnes with 18\% more as well.
|
||
% In the case of FAT allocator embedded inside jemalloc kmeans stands with 19\% more misses than the baseline allocator, memaccess with 77\%
|
||
% lesser misses, Glibc with 370\% more misses which is significant especially being malloc heavy benchmark, Richards has no difference in
|
||
% LL cache misses and barnes has a 68\% more cache misses.
|
||
% FAT allocator was near baseline for Kmeans but caused an 18\% increase in misses for Memaccess (designed to stress cache ),
|
||
% a 30\% increase for Richards (many dynamic allocations and pointer manipulations ), and an 18\% increase for Barnes (uses pointer-based octrees ). However,
|
||
% FAT allocator achieved a significant 60\% reduction in misses for the Glibc benchmark, which involves active memory use post-allocation.
|
||
% FAT allocator embedded inside Jemalloc showed a 75\% reduction in misses for Memaccess, a substantial improvement. Conversely, it led to an 18\% increase in
|
||
% misses for Kmeans, a massive 375\% increase for Glibc, and a 65\% increase for Barnes. For the Richards benchmark, its performance was at the baseline.
|
||
% This high variability indicates that memory placement strategies of the allocators interact diversely with the specific access patterns of each benchmark,
|
||
% such as the difference between the large data arrays in K-Means versus the linked structures common in Memaccess or Richards.
|
||
|
||
\item Wall clock (Figure~\ref{fig:wallclock}): Wallclock time serves as the definitive metric for evaluating overall execution performance.
|
||
When using the FAT allocator, glibc demonstrated the most significant improvement, with a 51\% reduction in wallclock
|
||
runtime compared to the baseline allocator. This was followed by memaccess with a 34\% decrease, barnes with a 4\% reduction,
|
||
and kmeans with a modest 1.8\% improvement.
|
||
Richards exhibited a slight increase of 1\% in runtime.
|
||
When the FAT allocator was integrated into Jemalloc, the performance impact varied. Glibc experienced a 16.2\% increase
|
||
in wallclock time, while barnes showed a 7\% rise. Both Richards and kmeans maintained the same runtime as the baseline
|
||
allocator.
|
||
In regards to memaccess (Figure~\ref{fig:Memaccess}) the comparative performance of two allocators FAT allocator embedded inside jemalloc
|
||
(depicted by the solid blue line with circular markers) and FAT allocator (represented by the dashed orange line with square markers)
|
||
across progressively increasing memory access iterations ranging from 500 to 64,000. The results indicate that the standalone FAT allocator
|
||
exhibits superior performance at smaller memory sizes, maintaining an initial lead of approximately 0.78\% at size 500. However,
|
||
its trajectory is characterised by minor fluctuations as memory size increases. Conversely, the jemalloc embedded allocator demonstrates
|
||
a more consistent and steadily rising performance pattern. The annotated red values denote the performance differential between the two
|
||
allocators. Although the FAT allocator retains an advantage in the lower ranges, this advantage progressively diminishes with increasing memory reads.
|
||
Notably, at the largest tested size of 64,000, the difference marginally reverses (–0.07), with the jemalloc-embedded allocator slightly outperforming.
|
||
Overall, the findings suggest that while the FAT allocator is more effective at smaller scales, the jemalloc embedded FAT allocator exhibits superior scalability
|
||
and reliability across larger memory reads.
|
||
|
||
% Wallclock time provides the ultimate measure of overall execution performance, In terms of the FAT allocator GLibc
|
||
% had a biggest difference of 51\% lesser wall clock run time than the baseline allocator, following this memaccess with a 34\% reduction
|
||
% , 3rd being Barnes being 4\% lesser, 4th being Kmeans with 1.8\% less and Richards having 1\% more. In terms of Jemalloc embedded inside
|
||
% the FAT allocator Glibc having a increased wall clock run time of 16.2\%, followed by Barnes with a 7\% increase, Richards and Kmeans
|
||
% with the same wall clock run time as the baseline allocator. Memaccess showed a decrease in the wall clock runtime by 4\%.
|
||
% where lower values (deviations below 100\%) indicate improvement.
|
||
% FAT allocator resulted in a 1\% speedup for Kmeans and a more significant 5\% speedup for Barnes. This improvement for Barnes was observed despite an increase
|
||
% in its LL cache misses, suggesting other factors such as reduced allocator overhead or better CPU pipeline utilization might have contributed.
|
||
% For Memaccess and Glibc, FAT allocator performed at the baseline. Notably, the substantial LL cache miss reduction seen with FAT allocator on Glibc did not
|
||
% translate into an overall speedup. It was about 1\% slower on Richards.
|
||
% FAT allocator embedded inside Jemalloc was 4\% faster for Memaccess, aligning well with its significant LL cache miss reduction and L1D TLB improvements
|
||
% for that benchmark. It performed at baseline for Kmeans and was negligibly faster (0.5\%) for Richards. However, it was 15\% slower for Glibc, a slowdown
|
||
% consistent with the massive increase in LL cache misses observed. For Barnes, it resulted in an 8\% slowdown, which also correlates with its increased
|
||
% LL cache misses for that benchmark. These wallclock results underscore that improvements in a single specific memory subsystem metric do not always guarantee
|
||
% an overall application speedup, as the interplay of various factors determines the final performance.
|
||
\end{itemize}
|
||
|
||
\begin{figure}[htbp]
|
||
\includegraphics[width=\linewidth]{diagram/benchmarks-group/Memaccess_size.png}
|
||
\caption{Memaccess percentage increase in wallclock run times}
|
||
\label{fig:Memaccess}
|
||
\end{figure}
|
||
|
||
A particularly striking observation is the significant reduction in data TLB walks,
|
||
L2 data TLB reads and TLB refills-consistently which show a 90\% decrease across all
|
||
benchmarks compared to Jemalloc. This improvement is due to the modified allocators
|
||
use of a single huge page entry at the L1 TLB layer. By enabling most address translations
|
||
to be resolved directly at the L1 TLB, the need to walk through the deeper TLB hierarchy is
|
||
largely eliminated. This reduction in translation overhead is a key factor in the allocators
|
||
performance for certain types of workloads.
|
||
|
||
The micro benchmarks which are crafted to emphasise memory read operations, highlight the
|
||
allocators strengths. These tests simulate frequent and intensive memory access patterns,
|
||
where the reduction in TLB misses directly translate into measurable performance gains.
|
||
On average, the FAT allocator achieves a 50\% reduction in wall clock runtimes for
|
||
these workloads underscoring its ability to optimise high-throughput memory operations.
|
||
|
||
On the other hand, macro benchmarks which represent larger and more complex real-world applications,
|
||
exhibit minimal differences in wall clock runtimes when using the FAT allocator.
|
||
This outcome is expected, as macro benchmarks typically involve a broader range of operations
|
||
beyond memory allocation. Additionally,
|
||
the benefits of huge pages may be less pronounced for these workloads, as they are often
|
||
bottlenecked by factors such as computation or I/O rather than memory translation overhead.
|
||
|
||
% \begin{figure}[htbp]
|
||
% \centering
|
||
% \includegraphics[width=1.1\linewidth]{./diagram/kmeans.png}
|
||
% \caption{\label{fig:org8683315}Kmeans COZ benchmark executed against various cluster sizes}
|
||
% \end{figure}
|
||
|
||
% The K-means algorithm was executed with varying cluster sizes as shown in figure~\ref{fig:org8683315}, to evaluate the performance difference
|
||
% between the FAT allocator and Jemalloc as the workload scales. This analysis
|
||
% aims to understand how the allocators optimisations, particularly its ability to manage memory
|
||
% more efficiently with huge pages, impact performance under different workload conditions.
|
||
|
||
% For most cluster sizes tested, the percentage difference in performance remained relatively
|
||
% consistent. This indicates that the allocators efficiency scales predictably with increasing
|
||
% workload sizes. Suggesting a stable and uniform benefit across different configurations. The
|
||
% consistent performance gain is likely due to the allocators ability to minimise TLB misses
|
||
% and efficiently manage memory allocations for the centroid and data point structures used in
|
||
% the K-means algorithm.
|
||
|
||
% However, an anomaly was observed at a cluster size of 200k, where the percentage difference
|
||
% deviated significantly from the trend. At this cluster size, the memory access patterns and allocation behavior may align in a way that
|
||
% temporarily offsets the advantages of the FAT allocator. For example, the memory layout
|
||
% might interact with system-level caching mechanisms or TLB behavior differently leading to an
|
||
% unexpected change in performance. Additionally, the increased complexity of managing a higher
|
||
% number of clusters might introduce computational overhead that overshadows the memory allocators
|
||
% optimisations.
|
||
|
||
% This observation highlights the importance of testing across a range of workload sizes and
|
||
% configurations to uncover edge cases or specific scenarios where performance deviates from the
|
||
% expected pattern. Understanding these anomalies can provide insights into the allocator's
|
||
% behavior and guide future improvements to address such outliers. Despite the deviation at a
|
||
% cluster size of 2000, the overall results reaffirm the allocator's capability to maintain
|
||
% consistent performance benefits across most scenarios.
|
||
|
||
% \subsection{Analysis}
|
||
% \label{sec:Analysis}
|
||
|
||
% The FAT memory allocator and the modified Jemalloc demonstrates significant potential for enhancing
|
||
% memory management in systems that benefit from huge page optimisations. Its design
|
||
% effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
|
||
% and TLB refills compared to the system allocator (i.e default Jemalloc). These improvements lead to noticeable performance
|
||
% gains especially in micro benchmarks, where the allocator reduces wall clock runtimes
|
||
% by an average of 50\%.
|
||
|
||
% The allocator integrates seamlessly into memory read intensive workloads, as evidenced by its
|
||
% consistent performance across varying cluster sizes in the K-means benchmark with only
|
||
% minor anomalies observed under specific conditions. These outliers provide valuable
|
||
% insights into the allocators interaction with system-level caching and memory translation mechanisms.
|
||
|
||
% While the allocator excels in scenarios emphasising on high-memory throughput. Its impact on
|
||
% macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
|
||
% applications with frequent and intensive memory operations rather than are compute-bound workloads.
|
||
|
||
% \section{Future work}
|
||
% The current experimental setup on the ARM Morello board is constrained by the requirement that all memory reads must
|
||
% pass through the (TLB) for address translation. This necessitates frequent TLB lookups, potentially
|
||
% leading to performance bottlenecks. The planned future work aims to address this by leveraging CHERI
|
||
% (Capability Hardware Enhanced RISC Instructions) extensions on the RISC-V architecture, specifically using the
|
||
% Tooba implementation.
|
||
|
||
% \subsection{Storing Offsets Directly on Pointers}
|
||
% 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. This is possible due to CHERI's capability model, which supports fine-grained memory protection and can encode bounds within pointers.
|
||
% Utilizing Bounds in CHERI for Block-Based Allocation:
|
||
|
||
% CHERI capabilities allow pointers to carry metadata about memory bounds, providing hardware-enforced memory safety.
|
||
% By encoding the offset and bounds within the pointer, the system can directly access memory without needing intermediate translations via the TLB.
|
||
% This enables the implementation of a block-based allocator that can efficiently manage memory allocations and deallocations within defined bounds.
|
||
% Bypassing the TLB in RISC-V Tooba.
|
||
|
||
% \subsection{Hardware Modifications:}
|
||
% 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 physical address from the capability information.
|
||
% This modification reduces the dependency on the TLB, decreasing latency and improving performance, especially for frequent memory operations.
|
||
|
||
\section{Conclusion} %Title of the Conclusion
|
||
This paper has presented FAT, a memory allocator
|
||
designed to address the growing mismatch between application memory demands and
|
||
the limited reach of TLBs in modern processors.
|
||
By leveraging physically contiguous memory through huge pages and embedding
|
||
allocation metadata within CHERI's compressed capability based pointers,
|
||
FAT significantly reduces the overhead associated with virtual-to-physical
|
||
address translation.
|
||
\newline
|
||
FAT achieves block-based allocation within huge pages, enabling memory tracking
|
||
without relying heavily on traditional page table mechanisms. Benchmark evaluations
|
||
demonstrate that FAT can reduce TLB walks by up to 99\%, resulting in substantial
|
||
performance improvements in memory-intensive workloads. When applied to
|
||
microbenchmarks, FAT reduced wall-clock runtime by up to 51\% for Glibc and
|
||
34\% for Memaccess, while also achieving up to 68\% fewer L1 TLB reads and 98\%
|
||
fewer L2 TLB reads. In contrast, macro benchmarks such as Kmeans and Barnes
|
||
showed more modest gains of 1.8\% and 4\% in runtime, respectively, reflecting
|
||
the allocator's limited impact in compute-bound scenarios.
|
||
\newline
|
||
Although performance gains are less significant for larger or computation-heavy applications,
|
||
the results underscore the allocator's potential to enhance memory management in
|
||
high-throughput environments. More broadly, this work demonstrates how
|
||
capability based architectures originally designed to ensure memory safety can
|
||
be effectively repurposed to optimise address translation.
|
||
FAT thus represents a promising direction for developing more scalable
|
||
and efficient memory allocation strategies in systems adopting
|
||
capability aware architectures.
|
||
% This paper addresses the growing disparity between application workloads and the capacity of TLBs.
|
||
% To mitigate this gap, FAT proposed leveraging physically contiguous memory with CHERI bounds to reduce TLB walks.
|
||
% FAT is a memory allocator that uses huge pages with the CHERI CC scheme to track allocations within the
|
||
% allocated huge page.
|
||
|
||
|
||
% This approach reduces the number of TLB entries needed while using bounds
|
||
% to minimise fragmentation.
|
||
% Additionally,
|
||
% the report explores advancements in system security, particularly through the Capability Hardware Enhanced RISC Instructions (CHERI)
|
||
% architecture. CHERI's capability-based addressing enhances system security by associating capabilities with memory pointers,
|
||
% restricting access to memory regions, and thus protecting against various security threats. Importantly, these mechanisms
|
||
% can also improve the reduction of TLB walks to memory allocators by using CHERI bounds while maintaining CHERI's security guarantees.
|
||
|
||
% \newline
|
||
% The benchmarks demonstrates the FAT allocator and the FAT allocator embedded within Jemalloc which reduces the TLB walks by upto 99\%,
|
||
% leading to substantial performance gains in memory-intensive workloads, though the improvements are less pronounced
|
||
% for larger and computation-heavy applications. These results highlight the allocators potential to advance memory management
|
||
% by repurposing CHERI's capability-based model with the use of huge pages.
|
||
|
||
|
||
|
||
|
||
|
||
% \section{Template Overview}
|
||
% As noted in the introduction, the ``\verb|acmart|'' document class can
|
||
% be used to prepare many different kinds of documentation --- a
|
||
% double-anonymous initial submission of a full-length technical paper, a
|
||
% two-page SIGGRAPH Emerging Technologies abstract, a ``camera-ready''
|
||
% journal article, a SIGCHI Extended Abstract, and more --- all by
|
||
% selecting the appropriate {\itshape template style} and {\itshape
|
||
% template parameters}.
|
||
|
||
% This document will explain the major features of the document
|
||
% class. For further information, the {\itshape \LaTeX\ User's Guide} is
|
||
% available from
|
||
% \url{https://www.acm.org/publications/proceedings-template}.
|
||
|
||
% \subsection{Template Styles}
|
||
|
||
% The primary parameter given to the ``\verb|acmart|'' document class is
|
||
% the {\itshape template style} which corresponds to the kind of publication
|
||
% or SIG publishing the work. This parameter is enclosed in square
|
||
% brackets and is a part of the {\verb|documentclass|} command:
|
||
% \begin{verbatim}
|
||
% \documentclass[STYLE]{acmart}
|
||
% \end{verbatim}
|
||
|
||
% Journals use one of three template styles. All but three ACM journals
|
||
% use the {\verb|acmsmall|} template style:
|
||
% \begin{itemize}
|
||
% \item {\texttt{acmsmall}}: The default journal template style.
|
||
% \item {\texttt{acmlarge}}: Used by JOCCH and TAP.
|
||
% \item {\texttt{acmtog}}: Used by TOG.
|
||
% \end{itemize}
|
||
|
||
% The majority of conference proceedings documentation will use the {\verb|acmconf|} template style.
|
||
% \begin{itemize}
|
||
% \item {\texttt{sigconf}}: The default proceedings template style.
|
||
% \item{\texttt{sigchi}}: Used for SIGCHI conference articles.
|
||
% \item{\texttt{sigplan}}: Used for SIGPLAN conference articles.
|
||
% \end{itemize}
|
||
|
||
% \subsection{Template Parameters}
|
||
|
||
% In addition to specifying the {\itshape template style} to be used in
|
||
% formatting your work, there are a number of {\itshape template parameters}
|
||
% which modify some part of the applied template style. A complete list
|
||
% of these parameters can be found in the {\itshape \LaTeX\ User's Guide.}
|
||
|
||
% Frequently-used parameters, or combinations of parameters, include:
|
||
% \begin{itemize}
|
||
% \item {\texttt{anonymous,review}}: Suitable for a ``double-anonymous''
|
||
% conference submission. Anonymizes the work and includes line
|
||
% numbers. Use with the \texttt{\acmSubmissionID} command to print the
|
||
% submission's unique ID on each page of the work.
|
||
% \item{\texttt{authorversion}}: Produces a version of the work suitable
|
||
% for posting by the author.
|
||
% \item{\texttt{screen}}: Produces colored hyperlinks.
|
||
% \end{itemize}
|
||
|
||
% This document uses the following string as the first command in the
|
||
% source file:
|
||
% \begin{verbatim}
|
||
% \documentclass[sigconf,authordraft]{acmart}
|
||
% \end{verbatim}
|
||
|
||
% \section{Modifications}
|
||
|
||
% Modifying the template --- including but not limited to: adjusting
|
||
% margins, typeface sizes, line spacing, paragraph and list definitions,
|
||
% and the use of the \verb|\vspace| command to manually adjust the
|
||
% vertical spacing between elements of your work --- is not allowed.
|
||
|
||
% {\bfseries Your document will be returned to you for revision if
|
||
% modifications are discovered.}
|
||
|
||
% \section{Typefaces}
|
||
|
||
% The ``\verb|acmart|'' document class requires the use of the
|
||
% ``Libertine'' typeface family. Your \TeX\ installation should include
|
||
% this set of packages. Please do not substitute other typefaces. The
|
||
% ``\verb|lmodern|'' and ``\verb|ltimes|'' packages should not be used,
|
||
% as they will override the built-in typeface families.
|
||
|
||
% \section{Title Information}
|
||
|
||
% The title of your work should use capital letters appropriately -
|
||
% \url{https://capitalizemytitle.com/} has useful rules for
|
||
% capitalization. Use the {\verb|title|} command to define the title of
|
||
% your work. If your work has a subtitle, define it with the
|
||
% {\verb|subtitle|} command. Do not insert line breaks in your title.
|
||
|
||
% If your title is lengthy, you must define a short version to be used
|
||
% in the page headers, to prevent overlapping text. The \verb|title|
|
||
% command has a ``short title'' parameter:
|
||
% \begin{verbatim}
|
||
% \title[short title]{full title}
|
||
% \end{verbatim}
|
||
|
||
% \section{Authors and Affiliations}
|
||
|
||
% Each author must be defined separately for accurate metadata
|
||
% identification. As an exception, multiple authors may share one
|
||
% affiliation. Authors' names should not be abbreviated; use full first
|
||
% names wherever possible. Include authors' e-mail addresses whenever
|
||
% possible.
|
||
|
||
% Grouping authors' names or e-mail addresses, or providing an ``e-mail
|
||
% alias,'' as shown below, is not acceptable:
|
||
% \begin{verbatim}
|
||
% \author{Brooke Aster, David Mehldau}
|
||
% \email{dave,judy,steve@university.edu}
|
||
% \email{firstname.lastname@phillips.org}
|
||
% \end{verbatim}
|
||
|
||
% The \verb|authornote| and \verb|authornotemark| commands allow a note
|
||
% to apply to multiple authors --- for example, if the first two authors
|
||
% of an article contributed equally to the work.
|
||
|
||
% If your author list is lengthy, you must define a shortened version of
|
||
% the list of authors to be used in the page headers, to prevent
|
||
% overlapping text. The following command should be placed just after
|
||
% the last \verb|\author{}| definition:
|
||
% \begin{verbatim}
|
||
% \renewcommand{\shortauthors}{McCartney, et al.}
|
||
% \end{verbatim}
|
||
% Omitting this command will force the use of a concatenated list of all
|
||
% of the authors' names, which may result in overlapping text in the
|
||
% page headers.
|
||
|
||
% The article template's documentation, available at
|
||
% \url{https://www.acm.org/publications/proceedings-template}, has a
|
||
% complete explanation of these commands and tips for their effective
|
||
% use.
|
||
|
||
% Note that authors' addresses are mandatory for journal articles.
|
||
|
||
% \section{Rights Information}
|
||
|
||
% Authors of any work published by ACM will need to complete a rights
|
||
% form. Depending on the kind of work, and the rights management choice
|
||
% made by the author, this may be copyright transfer, permission,
|
||
% license, or an OA (open access) agreement.
|
||
|
||
% Regardless of the rights management choice, the author will receive a
|
||
% copy of the completed rights form once it has been submitted. This
|
||
% form contains \LaTeX\ commands that must be copied into the source
|
||
% document. When the document source is compiled, these commands and
|
||
% their parameters add formatted text to several areas of the final
|
||
% document:
|
||
% \begin{itemize}
|
||
% \item the ``ACM Reference Format'' text on the first page.
|
||
% \item the ``rights management'' text on the first page.
|
||
% \item the conference information in the page header(s).
|
||
% \end{itemize}
|
||
|
||
% Rights information is unique to the work; if you are preparing several
|
||
% works for an event, make sure to use the correct set of commands with
|
||
% each of the works.
|
||
|
||
% The ACM Reference Format text is required for all articles over one
|
||
% page in length, and is optional for one-page articles (abstracts).
|
||
|
||
% \section{CCS Concepts and User-Defined Keywords}
|
||
|
||
% Two elements of the ``acmart'' document class provide powerful
|
||
% taxonomic tools for you to help readers find your work in an online
|
||
% search.
|
||
|
||
% The ACM Computing Classification System ---
|
||
% \url{https://www.acm.org/publications/class-2012} --- is a set of
|
||
% classifiers and concepts that describe the computing
|
||
% discipline. Authors can select entries from this classification
|
||
% system, via \url{https://dl.acm.org/ccs/ccs.cfm}, and generate the
|
||
% commands to be included in the \LaTeX\ source.
|
||
|
||
% User-defined keywords are a comma-separated list of words and phrases
|
||
% of the authors' choosing, providing a more flexible way of describing
|
||
% the research being presented.
|
||
|
||
% CCS concepts and user-defined keywords are required for for all
|
||
% articles over two pages in length, and are optional for one- and
|
||
% two-page articles (or abstracts).
|
||
|
||
% \section{Sectioning Commands}
|
||
|
||
% Your work should use standard \LaTeX\ sectioning commands:
|
||
% \verb|section|, \verb|subsection|, \verb|subsubsection|, and
|
||
% \verb|paragraph|. They should be numbered; do not remove the numbering
|
||
% from the commands.
|
||
|
||
% Simulating a sectioning command by setting the first word or words of
|
||
% a paragraph in boldface or italicized text is {\bfseries not allowed.}
|
||
|
||
% \section{Tables}
|
||
|
||
% The ``\verb|acmart|'' document class includes the ``\verb|booktabs|''
|
||
% package --- \url{https://ctan.org/pkg/booktabs} --- for preparing
|
||
% high-quality tables.
|
||
|
||
% Table captions are placed {\itshape above} the table.
|
||
|
||
% Because tables cannot be split across pages, the best placement for
|
||
% them is typically the top of the page nearest their initial cite. To
|
||
% ensure this proper ``floating'' placement of tables, use the
|
||
% environment \textbf{table} to enclose the table's contents and the
|
||
% table caption. The contents of the table itself must go in the
|
||
% \textbf{tabular} environment, to be aligned properly in rows and
|
||
% columns, with the desired horizontal and vertical rules. Again,
|
||
% detailed instructions on \textbf{tabular} material are found in the
|
||
% \textit{\LaTeX\ User's Guide}.
|
||
|
||
% Immediately following this sentence is the point at which
|
||
% Table~\ref{tab:freq} is included in the input file; compare the
|
||
% placement of the table here with the table in the printed output of
|
||
% this document.
|
||
|
||
% \begin{table}
|
||
% \caption{Frequency of Special Characters}
|
||
% \label{tab:freq}
|
||
% \begin{tabular}{ccl}
|
||
% \toprule
|
||
% Non-English or Math&Frequency&Comments\\
|
||
% \midrule
|
||
% \O & 1 in 1,000& For Swedish names\\
|
||
% $\pi$ & 1 in 5& Common in math\\
|
||
% \$ & 4 in 5 & Used in business\\
|
||
% $\Psi^2_1$ & 1 in 40,000& Unexplained usage\\
|
||
% \bottomrule
|
||
% \end{tabular}
|
||
% \end{table}
|
||
|
||
% To set a wider table, which takes up the whole width of the page's
|
||
% live area, use the environment \textbf{table*} to enclose the table's
|
||
% contents and the table caption. As with a single-column table, this
|
||
% wide table will ``float'' to a location deemed more
|
||
% desirable. Immediately following this sentence is the point at which
|
||
% Table~\ref{tab:commands} is included in the input file; again, it is
|
||
% instructive to compare the placement of the table here with the table
|
||
% in the printed output of this document.
|
||
|
||
% \begin{table*}
|
||
% \caption{Some Typical Commands}
|
||
% \label{tab:commands}
|
||
% \begin{tabular}{ccl}
|
||
% \toprule
|
||
% Command &A Number & Comments\\
|
||
% \midrule
|
||
% \texttt{{\char'134}author} & 100& Author \\
|
||
% \texttt{{\char'134}table}& 300 & For tables\\
|
||
% \texttt{{\char'134}table*}& 400& For wider tables\\
|
||
% \bottomrule
|
||
% \end{tabular}
|
||
% \end{table*}
|
||
|
||
% Always use midrule to separate table header rows from data rows, and
|
||
% use it only for this purpose. This enables assistive technologies to
|
||
% recognise table headers and support their users in navigating tables
|
||
% more easily.
|
||
|
||
% \section{Math Equations}
|
||
% You may want to display math equations in three distinct styles:
|
||
% inline, numbered or non-numbered display. Each of the three are
|
||
% discussed in the next sections.
|
||
|
||
% \subsection{Inline (In-text) Equations}
|
||
% A formula that appears in the running text is called an inline or
|
||
% in-text formula. It is produced by the \textbf{math} environment,
|
||
% which can be invoked with the usual
|
||
% \texttt{{\char'134}begin\,\ldots{\char'134}end} construction or with
|
||
% the short form \texttt{\$\,\ldots\$}. You can use any of the symbols
|
||
% and structures, from $\alpha$ to $\omega$, available in
|
||
% \LaTeX~~\cite{Lamport:LaTeX}; this section will simply show a few
|
||
% examples of in-text equations in context. Notice how this equation:
|
||
% \begin{math}
|
||
% \lim_{n\rightarrow \infty}x=0
|
||
% \end{math},
|
||
% set here in in-line math style, looks slightly different when
|
||
% set in display style. (See next section).
|
||
|
||
% \subsection{Display Equations}
|
||
% A numbered display equation---one set off by vertical space from the
|
||
% text and centered horizontally---is produced by the \textbf{equation}
|
||
% environment. An unnumbered display equation is produced by the
|
||
% \textbf{displaymath} environment.
|
||
|
||
% Again, in either environment, you can use any of the symbols and
|
||
% structures available in \LaTeX\@; this section will just give a couple
|
||
% of examples of display equations in context. First, consider the
|
||
% equation, shown as an inline equation above:
|
||
% \begin{equation}
|
||
% \lim_{n\rightarrow \infty}x=0
|
||
% \end{equation}
|
||
% Notice how it is formatted somewhat differently in
|
||
% the \textbf{displaymath}
|
||
% environment. Now, we'll enter an unnumbered equation:
|
||
% \begin{displaymath}
|
||
% \sum_{i=0}^{\infty} x + 1
|
||
% \end{displaymath}
|
||
% and follow it with another numbered equation:
|
||
% \begin{equation}
|
||
% \sum_{i=0}^{\infty}x_i=\int_{0}^{\pi+2} f
|
||
% \end{equation}
|
||
% just to demonstrate \LaTeX's able handling of numbering.
|
||
|
||
% \section{Figures}
|
||
|
||
% The ``\verb|figure|'' environment should be used for figures. One or
|
||
% more images can be placed within a figure. If your figure contains
|
||
% third-party material, you must clearly identify it as such, as shown
|
||
% in the example below.
|
||
% % \begin{figure}[h]
|
||
% % \centering
|
||
% % \includegraphics[width=\linewidth]{sample-franklin}
|
||
% % \caption{1907 Franklin Model D roadster. Photograph by Harris \&
|
||
% % Ewing, Inc. [Public domain], via Wikimedia
|
||
% % Commons. (\url{https://goo.gl/VLCRBB}).}
|
||
% % \Description{A woman and a girl in white dresses sit in an open car.}
|
||
% % \end{figure}
|
||
|
||
% Your figures should contain a caption which describes the figure to
|
||
% the reader.
|
||
|
||
% Figure captions are placed {\itshape below} the figure.
|
||
|
||
% Every figure should also have a figure description unless it is purely
|
||
% decorative. These descriptions convey what’s in the image to someone
|
||
% who cannot see it. They are also used by search engine crawlers for
|
||
% indexing images, and when images cannot be loaded.
|
||
|
||
% A figure description must be unformatted plain text less than 2000
|
||
% characters long (including spaces). {\bfseries Figure descriptions
|
||
% should not repeat the figure caption – their purpose is to capture
|
||
% important information that is not already provided in the caption or
|
||
% the main text of the paper.} For figures that convey important and
|
||
% complex new information, a short text description may not be
|
||
% adequate. More complex alternative descriptions can be placed in an
|
||
% appendix and referenced in a short figure description. For example,
|
||
% provide a data table capturing the information in a bar chart, or a
|
||
% structured list representing a graph. For additional information
|
||
% regarding how best to write figure descriptions and why doing this is
|
||
% so important, please see
|
||
% \url{https://www.acm.org/publications/taps/describing-figures/}.
|
||
|
||
% \subsection{The ``Teaser Figure''}
|
||
|
||
% A ``teaser figure'' is an image, or set of images in one figure, that
|
||
% are placed after all author and affiliation information, and before
|
||
% the body of the article, spanning the page. If you wish to have such a
|
||
% figure in your article, place the command immediately before the
|
||
% \verb|\maketitle| command:
|
||
% % \begin{verbatim}
|
||
% % \begin{teaserfigure}
|
||
% % \includegraphics[width=\textwidth]{sampleteaser}
|
||
% % \caption{figure caption}
|
||
% % \Description{figure description}
|
||
% % \end{teaserfigure}
|
||
% % \end{verbatim}
|
||
|
||
% \section{Citations and Bibliographies}
|
||
|
||
% The use of \BibTeX\ for the preparation and formatting of one's
|
||
% references is strongly recommended. Authors' names should be complete
|
||
% --- use full first names (``Donald E. Knuth'') not initials
|
||
% (``D. E. Knuth'') --- and the salient identifying features of a
|
||
% reference should be included: title, year, volume, number, pages,
|
||
% article DOI, etc.
|
||
|
||
% The bibliography is included in your source document with these two
|
||
% commands, placed just before the \verb|\end{document}| command:
|
||
% \begin{verbatim}
|
||
% \bibliographystyle{ACM-Reference-Format}
|
||
% \bibliography{bibfile}
|
||
% \end{verbatim}
|
||
% where ``\verb|bibfile|'' is the name, without the ``\verb|.bib|''
|
||
% suffix, of the \BibTeX\ file.
|
||
|
||
% Citations and references are numbered by default. A small number of
|
||
% ACM publications have citations and references formatted in the
|
||
% ``author year'' style; for these exceptions, please include this
|
||
% command in the {\bfseries preamble} (before the command
|
||
% ``\verb|\begin{document}|'') of your \LaTeX\ source:
|
||
% \begin{verbatim}
|
||
% ~\citestyle{acmauthoryear}
|
||
% \end{verbatim}
|
||
|
||
|
||
% Some examples. A paginated journal article ~\cite{Abril07}, an
|
||
% enumerated journal article ~\cite{Cohen07}, a reference to an entire
|
||
% issue ~\cite{JCohen96}, a monograph (whole book) ~\cite{Kosiur01}, a
|
||
% monograph/whole book in a series (see 2a in spec. document)
|
||
% ~\cite{Harel79}, a divisible-book such as an anthology or compilation
|
||
% ~\cite{Editor00} followed by the same example, however we only output
|
||
% the series if the volume number is given ~\cite{Editor00a} (so
|
||
% Editor00a's series should NOT be present since it has no vol. no.),
|
||
% a chapter in a divisible book ~\cite{Spector90}, a chapter in a
|
||
% divisible book in a series ~\cite{Douglass98}, a multi-volume work as
|
||
% book ~\cite{Knuth97}, a couple of articles in a proceedings (of a
|
||
% conference, symposium, workshop for example) (paginated proceedings
|
||
% article) ~\cite{Andler79, Hagerup1993}, a proceedings article with
|
||
% all possible elements ~\cite{Smith10}, an example of an enumerated
|
||
% proceedings article ~\cite{VanGundy07}, an informally published work
|
||
% ~\cite{Harel78}, a couple of preprints ~\cite{Bornmann2019,
|
||
% AnzarootPBM14}, a doctoral dissertation ~\cite{Clarkson85}, a
|
||
% master's thesis: ~\cite{anisi03}, an online document / world wide web
|
||
% resource ~\cite{Thornburg01, Ablamowicz07, Poker06}, a video game
|
||
% (Case 1) ~\cite{Obama08} and (Case 2) ~\cite{Novak03} and ~\cite{Lee05}
|
||
% and (Case 3) a patent ~\cite{JoeScientist001}, work accepted for
|
||
% publication ~\cite{rous08}, 'YYYYb'-test for prolific author
|
||
% ~\cite{SaeediMEJ10} and ~\cite{SaeediJETC10}. Other cites might
|
||
% contain 'duplicate' DOI and URLs (some SIAM articles)
|
||
% ~\cite{Kirschmer:2010:AEI:1958016.1958018}. Boris / Barbara Beeton:
|
||
% multi-volume works as books ~\cite{MR781536} and ~\cite{MR781537}. A
|
||
% couple of citations with DOIs:
|
||
% ~\cite{2004:ITE:1009386.1010128,Kirschmer:2010:AEI:1958016.1958018}. Online
|
||
% citations: ~\cite{TUGInstmem, Thornburg01, CTANacmart}.
|
||
% Artifacts: ~\cite{R} and ~\cite{UMassCitations}.
|
||
|
||
% \section{Acknowledgments}
|
||
|
||
% Identification of funding sources and other support, and thanks to
|
||
% individuals and groups that assisted in the research and the
|
||
% preparation of the work should be included in an acknowledgment
|
||
% section, which is placed just before the reference section in your
|
||
% document.
|
||
|
||
% This section has a special environment:
|
||
% \begin{verbatim}
|
||
% \begin{acks}
|
||
% ...
|
||
% \end{acks}
|
||
% \end{verbatim}
|
||
% so that the information contained therein can be more easily collected
|
||
% during the article metadata extraction phase, and to ensure
|
||
% consistency in the spelling of the section heading.
|
||
|
||
% Authors should not prepare this section as a numbered or unnumbered {\verb|\section|}; please use the ``{\verb|acks|}'' environment.
|
||
|
||
% \section{Appendices}
|
||
|
||
% If your work needs an appendix, add it before the
|
||
% ``\verb|\end{document}|'' command at the conclusion of your source
|
||
% document.
|
||
|
||
% Start the appendix with the ``\verb|appendix|'' command:
|
||
% \begin{verbatim}
|
||
% \appendix
|
||
% \end{verbatim}
|
||
% and note that in the appendix, sections are lettered, not
|
||
% numbered. This document has two appendices, demonstrating the section
|
||
% and subsection identification method.
|
||
|
||
% \section{Multi-language papers}
|
||
|
||
% Papers may be written in languages other than English or include
|
||
% titles, subtitles, keywords and abstracts in different languages (as a
|
||
% rule, a paper in a language other than English should include an
|
||
% English title and an English abstract). Use \verb|language=...| for
|
||
% every language used in the paper. The last language indicated is the
|
||
% main language of the paper. For example, a French paper with
|
||
% additional titles and abstracts in English and German may start with
|
||
% the following command
|
||
% \begin{verbatim}
|
||
% \documentclass[sigconf, language=english, language=german,
|
||
% language=french]{acmart}
|
||
% \end{verbatim}
|
||
|
||
% The title, subtitle, keywords and abstract will be typeset in the main
|
||
% language of the paper. The commands \verb|\translatedXXX|, \verb|XXX|
|
||
% begin title, subtitle and keywords, can be used to set these elements
|
||
% in the other languages. The environment \verb|translatedabstract| is
|
||
% used to set the translation of the abstract. These commands and
|
||
% environment have a mandatory first argument: the language of the
|
||
% second argument. See \verb|sample-sigconf-i13n.tex| file for examples
|
||
% of their usage.
|
||
|
||
% \section{SIGCHI Extended Abstracts}
|
||
|
||
% The ``\verb|sigchi-a|'' template style (available only in \LaTeX\ and
|
||
% not in Word) produces a landscape-orientation formatted article, with
|
||
% a wide left margin. Three environments are available for use with the
|
||
% ``\verb|sigchi-a|'' template style, and produce formatted output in
|
||
% the margin:
|
||
% \begin{description}
|
||
% \item[\texttt{sidebar}:] Place formatted text in the margin.
|
||
% \item[\texttt{marginfigure}:] Place a figure in the margin.
|
||
% \item[\texttt{margintable}:] Place a table in the margin.
|
||
% \end{description}
|
||
|
||
% %%
|
||
% %% The acknowledgments section is defined using the "acks" environment
|
||
% %% (and NOT an unnumbered section). This ensures the proper
|
||
% %% identification of the section in the article metadata, and the
|
||
% %% consistent spelling of the heading.
|
||
% \begin{acks}
|
||
% To Robert, for the bagels and explaining CMYK and color spaces.
|
||
% \end{acks}
|
||
|
||
% %%
|
||
% %% The next two lines define the bibliography style to be used, and
|
||
% %% the bibliography file.
|
||
% \bibliographystyle{ACM-Reference-Format}
|
||
% \bibliography{sample-base}
|
||
|
||
|
||
% %%
|
||
% %% If your work has an appendix, this is the place to put it.
|
||
% \appendix
|
||
|
||
% \section{Research Methods}
|
||
|
||
% \subsection{Part One}
|
||
|
||
% Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi
|
||
% malesuada, quam in pulvinar varius, metus nunc fermentum urna, id
|
||
% sollicitudin purus odio sit amet enim. Aliquam ullamcorper eu ipsum
|
||
% vel mollis. Curabitur quis dictum nisl. Phasellus vel semper risus, et
|
||
% lacinia dolor. Integer ultricies commodo sem nec semper.
|
||
|
||
% \subsection{Part Two}
|
||
|
||
% Etiam commodo feugiat nisl pulvinar pellentesque. Etiam auctor sodales
|
||
% ligula, non varius nibh pulvinar semper. Suspendisse nec lectus non
|
||
% ipsum convallis congue hendrerit vitae sapien. Donec at laoreet
|
||
% eros. Vivamus non purus placerat, scelerisque diam eu, cursus
|
||
% ante. Etiam aliquam tortor auctor efficitur mattis.
|
||
|
||
% \section{Online Resources}
|
||
|
||
% Nam id fermentum dui. Suspendisse sagittis tortor a nulla mollis, in
|
||
% pulvinar ex pretium. Sed interdum orci quis metus euismod, et sagittis
|
||
% enim maximus. Vestibulum gravida massa ut felis suscipit
|
||
% congue. Quisque mattis elit a risus ultrices commodo venenatis eget
|
||
% dui. Etiam sagittis eleifend elementum.
|
||
|
||
% Nam interdum magna at lectus dignissim, ac dignissim lorem
|
||
% rhoncus. Maecenas eu arcu ac neque placerat aliquam. Nunc pulvinar
|
||
% massa et mattis lacinia.
|
||
|
||
\bibliographystyle{unsrtnat}
|
||
\bibliography{paperReferences}
|
||
|
||
\end{document}
|
||
\endinput
|
||
%%
|
||
%% End of file `sample-sigconf-authordraft.tex'.
|
||
|