1604 lines
82 KiB
TeX
1604 lines
82 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}
|
||
|
||
\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 Address Translations}
|
||
|
||
%%
|
||
%% 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) means TLB misses
|
||
are more frequency, costing additional clock cycles, impacting runtime performance. One solution is to use physically contiguous
|
||
memory in conjunction with huge pages. We propose an alternative approach, by exploiting capability-based addressing in the
|
||
CHERI architecture. This paper presents a new memory allocator. It associates capabilities with memory pointers. integrating
|
||
block-based allocations within huge pages. Our allocator reduces TLB misses by up to 90\%, which leads to reduced runtimes
|
||
for memory-intensive applications.
|
||
\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
|
||
applications handle increasingly complex workloads. Memory management is a key factor
|
||
in performance, where efficient use of resources is essential. Translation Lookaside
|
||
Buffers (TLBs) are crucial in this context, speeding up memory access by caching recent
|
||
memory address translations. A TLB, a specialised cache in the memory management unit (MMU),
|
||
reduces the time required to convert virtual addresses to physical ones. When a program accesses
|
||
data in memory, the MMU first checks the TLB for a matching entry, avoiding the slower process of
|
||
consulting page tables. However, as applications grow larger and more complex, the fixed size of
|
||
TLBs often cannot keep up, leading to more TLB misses and 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. By reducing the number of TLB entries needed to access a given amount
|
||
of memory, huge pages offer a potential avenue for optimising TLBs use 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. By 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.
|
||
|
||
Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
|
||
~\cite{woodruff_cheri_2014} 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 opens avenues for optimising memory management
|
||
operations. By integrating CHERI’s compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, We have shown it is possible to track and manage
|
||
large, physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces TLB pressure by minimising the number of
|
||
entries required to map extensive memory regions, thereby decreasing TLB misses and improving address translation performance.
|
||
Furthermore, it accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
|
||
memory allocations. 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 Optimization}: Demonstrates how CHERI's architecture can be
|
||
used to optimize memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
|
||
(Section ~\ref{sec:128bitCompressedBounds}).
|
||
|
||
\item \textbf{Memory Allocation Algorithms}: Provides an algorithms for allocating, freeing
|
||
physically contiguous memory and integrating huge pages with CHERI's capability-based bounds for enhanced memory management
|
||
(Section ~\ref{sec:MemoryAllocator}).
|
||
\end{itemize}
|
||
|
||
Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s ability
|
||
to reduce TLB misses by up to 90\%, yielding significant improvements in wall clock runtimes for memory-intensive
|
||
applications. While its impact on larger, 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, backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
|
||
and HugeTLBFS in Linux. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues.
|
||
|
||
% 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), but using a 2 MB huge page would waste
|
||
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium, which
|
||
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organize huge
|
||
pages, but 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 size, 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, 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 in certain scenarios.
|
||
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, creating ranges that
|
||
are both virtually and physically contiguous. This approach simplifies address translation
|
||
within these ranges by adding an offset, similar to Direct Segment, but RMM supports multiple
|
||
ranges and operates transparently to programmers, requiring no source code modifications.
|
||
The range table, 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, a process that is computationally expensive and therefore performed
|
||
only after an L1 TLB miss. To optimize this, RMM uses a range TLB (RTLB) to quickly identify
|
||
if an address falls within any pre-allocated range, facilitating efficient translation and
|
||
reducing overhead. Range mapping works alongside the paging system by generating TLB entries on
|
||
TLB misses and still performing TLB lookups for each virtual address translation.
|
||
Unlike traditional segmentation mechanisms, range mapping activates a range lookaside
|
||
buffer (RTLB) located with the last level TLB upon a miss. The hardware TLB miss
|
||
handler then searches the RTLB for the miss address and, if found, generates a new
|
||
TLB entry with the physical address derived from the base virtual address and
|
||
range offset, along with 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 in the background, avoiding delays in memory operations.
|
||
The RTLB, functioning as a fully associative search structure, ensures
|
||
that most last level TLB misses are handled efficiently by range mapping,
|
||
reducing the need for costly page table walks.
|
||
|
||
\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 compartmentalization. It is a hybrid capability
|
||
architecture that can combine capabilities with conventional MMU (Memory Management Unit)
|
||
based systems. The contributions of CHERI include ISA changes to introduce architectural
|
||
capabilities; a new microarchitecture that demonstrates capabilities can be implemented efficiently in hardware,
|
||
with support for efficient tagged memory to protect capabilities and compress them to reduce memory overhead;
|
||
a newly designed software construction model that uses capabilities to provide fine-grained memory protection and scalable
|
||
software compartmentalization; language and compiler extensions for using capabilities with C and C++; and OS extensions to
|
||
support fine-grained memory protection (including spatial, referential, and non-stack temporal memory safety) and abstraction extensions
|
||
for scalable software compartmentalization.
|
||
|
||
\subsection{CHERI CC}
|
||
CHERI Concentrate: Practical Compressed Capabilities\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI, aiming to address the performance and compatibility challenges associated with
|
||
capability pointers. Capability pointers enhance memory safety by embedding bounds and permissions directly
|
||
within pointers, but traditional implementations double their size—leading to increased memory usage. CHERI CC
|
||
proposes a compression strategy that preserves security while reducing size and inefficiencies. Key contributions include a floating-point
|
||
bounds encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimized space usage for larger ones.
|
||
|
||
\section{Fat Address Translations}
|
||
\label{sec:FatPointerTranslations}
|
||
Fat Address Translations (FAT) uses the CHERI architecture to
|
||
bring about block based allocations in physically contiguous memory.
|
||
FAT leverages techniques like FlexPointer~\cite{chen_flexpointer_2023} and RMM~\cite{karakostas_redundant_2015} 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*}[h]
|
||
\includegraphics[width=0.6\textwidth]{diagram/HighOverviewArchitecture.drawio.png}
|
||
\caption{High overview architecture}
|
||
\label{fig:HighOverviewArchitecture}
|
||
% \end{minipage}
|
||
\end{figure*}
|
||
|
||
Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (\textit{malloc()}) and a proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit
|
||
virtual addresses and a TLB walker (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 Address Translations 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.
|
||
A memory range in FAT has two points to track memory in physical contiguous space which
|
||
is the top and bottom. These two points are two virtual addresses and the range consists of
|
||
addresses which lie within this and refers to addresses allocated by invoking \textit{malloc}.
|
||
In FAT memory ranges are established using
|
||
bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019}.
|
||
% 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 the huge page.
|
||
The allocations use the bounds encoded in the FAT, ensuring tracking of the allocated memory regions.
|
||
By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page.
|
||
|
||
\subsection{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.
|
||
|
||
We use 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 which 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 a more flexible alternative to the traditional fixed-size TLB model.
|
||
|
||
% 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}.
|
||
We are able to pre-allocate memory using huge pages and are able to mark smaller allocations
|
||
using ranges by storing them as bounds within the pointer. Each of these memory ranges can be
|
||
called as a block. Since we have numerous blocks inside a huge page we allow block based
|
||
memory patters 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 a sample access to read within a contigous
|
||
space of physical memory. The dotted lines represents the
|
||
bounds for that particular pointer access. Using bounds
|
||
stored on the pointer a block based pattern can be replicated
|
||
on physically contigous memory.
|
||
|
||
\section{Memory allocator design}
|
||
\label{sec:MemoryAllocator}
|
||
This section presents a straightforward memory allocator designed and implemented based on the
|
||
principles outlined FAT (Section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: \textit{InitAlloc},
|
||
\textit{malloc}, and \textit{free}. The \textit{InitAlloc} function initializes 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, while the \textit{free}
|
||
function deallocates the memory, returning it to the pool for future use.
|
||
|
||
% A notable feature of this malloc implementation is its compatibility with kernel modules,
|
||
% where it can be integrated as an alternative to the mmap system call. This integration
|
||
% ensures that memory allocations are physically contiguous. 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, which constructs a FAT specialized
|
||
pointer that encodes both the start and end addresses of the allocated memory region within the pointer
|
||
itself. The start and end addresses correspond to the size of the memory block requested by \textit{malloc}. This
|
||
approach introduces a method of memory tracking, where the bounds of the allocated region are
|
||
explicitly encoded in the address, enabling efficient monitoring and management of memory usage.
|
||
|
||
Furthermore, this design uses shared 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 aligns with the principles of
|
||
efficient memory management but also demonstrates a practical usecase 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 the FAT to determine the range and size of the allocated memory region.
|
||
Specifically, FAT encodes the start and end addresses of each allocation, providing 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 initialization of physically contiguous memory through the use of huge pages,
|
||
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
|
||
allocating a fixed block of 1 GB of physically contiguous memory. This decision is driven by the
|
||
architectural constraints of contemporary systems, particularly ARM-based CPUs, where 1 GB represents
|
||
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
|
||
with page table management and enhances memory access efficiency, which is critical for performance-sensitive
|
||
applications and kernel-level operations.
|
||
|
||
\section{Evaluation}
|
||
\label{sec:Evaluation}
|
||
We conducted tests of the FAT memory allocator against Jemalloc~\cite{jemalloc},
|
||
Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}, to assess the performance improvements
|
||
enabled by the FAT allocator. Specifically, we evaluated
|
||
the reduction in TLB walks and misses and its impact on wall clock runtime.
|
||
|
||
To comprehensively analyze the proposed allocator, we categorized benchmarks into
|
||
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
|
||
C programs designed to target specific allocator patterns, enabling us to evaluate
|
||
detailed aspects of the allocator's behavior. Macro benchmarks, on the other hand,
|
||
encompass larger, real-world C programs, allowing us to assess the allocator's
|
||
performance in more practical, 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 ARM A76 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, ensuring compatibility with CHERI's capability-based
|
||
memory model. When compiling the C programs for benchmarking, the Benchmark ABI was
|
||
used as recommended by the CHERI community. This compilation mode was enabled using
|
||
the Clang compiler.
|
||
|
||
The Benchmark ABI~\cite{BenchmarkABI} 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 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 modified C allocator, imported as a header file. This approach was necessary
|
||
because the Benchmark ABI shared object file exhibited unexpected behavior,
|
||
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 were carried out using ARM 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/cpu\_cycles) CPU cycles & The CPU CYCLES counter increases with \\
|
||
& every clock cycle. However, it can be \\
|
||
& affected by changes in clock frequency, \\
|
||
& such as when WFI (Wait for Interrupt) \\
|
||
& or WFE (Wait for Event) \\
|
||
& instructions pause the clock. \\
|
||
& \\
|
||
(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}
|
||
\end{table*}
|
||
|
||
\subsection{Benchmarks}
|
||
The benchmarks~\cite{Benchmark} are classified into 2 classes:
|
||
|
||
\subsubsection{Micro benchmark}
|
||
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 involved real-world applications, offering insights into how
|
||
the allocator performs with complex memory allocation demands, large datasets,
|
||
and varying execution contexts.
|
||
\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 and
|
||
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 analyze performance variations.
|
||
\item \texttt{MemAccess}: This benchmark by Alex Bordei 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
|
||
randomized structures, optional node operations, and multithreaded
|
||
traversal using pthreads. The program dynamically allocates memory and systematically
|
||
doubles the working set size to analyze memory hierarchy behavior.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Macro benchmark}
|
||
\label{sec:Macro}
|
||
|
||
\begin{itemize}
|
||
\item \texttt{Kmeans}: Kmeans implements a parallelized K-means clustering algorithm that
|
||
assigns data points to clusters based on proximity to centroids,
|
||
iteratively updating them until convergence. The computation is
|
||
distributed across threads using the pthread library, dynamically
|
||
assigning tasks to optimize performance. Parameters like data size
|
||
and clusters are configurable, and the program ensures efficient
|
||
memory management and synchronization.
|
||
\item \texttt{Richards}: Richards is a task scheduling benchmark that simulates a
|
||
multitasking environment with tasks of varying types and priorities,
|
||
communicating through queued packets. The schedule function manages
|
||
task execution based on state and priority, tracking processed packets
|
||
and held tasks for performance evaluation. Configurable iterations and
|
||
timing help measure system performance and 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}. The implementation we benchmark 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}
|
||
\label{sec:Results}
|
||
|
||
\begin{figure*}[h]
|
||
\includegraphics[width=.9\linewidth]{diagram/bargraph.png}
|
||
\caption{\label{fig:bargraph}Percentage difference between the modified memory allocator against the default system memory allocator}
|
||
\end{figure*}
|
||
|
||
The graph (Figure \ref{fig:bargraph}) highlights the performance comparison between the modified memory allocator and
|
||
Jemalloc, the default memory allocator. The FAT memory allocator, specifically optimized
|
||
for use with huge pages, demonstrates a clear advantage in scenarios where memory allocation
|
||
patterns benefit from its design. The results align with expectations, showcasing the impact
|
||
of its capability to handle memory more efficiently by leveraging huge pages.
|
||
|
||
\begin{itemize}
|
||
\item L1 DTLB reads: There was noticeable reduction of L1 DTLB reads for kmeans of about an average of
|
||
4\% lesser and for Glibc there was significant reduction of 50\% lesser than Jemalloc.
|
||
|
||
\item L2 DTLB reads: For all the benchmarks on figure \ref{fig:bargraph} there was on average 98\%
|
||
reduction on L2 DTLB reads. This demonstrates that all the TLB translations are read at the L1 TLB
|
||
cache.
|
||
|
||
\item DTLB walks: Due to most of the TLB entries getting hit at the L1 DTLB there is no need
|
||
to walk the TLB cache hierarchy. This is shown by an average of 99\% reduction in DTLB walks.
|
||
|
||
\item L1 DTLB refills: Since there are fewer DTLB walks and most reads are done at the L1 DTLB
|
||
layer there is no need for numerous TLB refills to take place. Our benchmarks show on average
|
||
a 99\% reduction on DTLB refills.
|
||
|
||
\end{itemize}
|
||
|
||
A particularly striking observation is the significant reduction in data TLB walks,
|
||
L2 data TLB reads, and TLB refills—consistently showing a 90\% decrease across all
|
||
benchmarks compared to Jemalloc. This improvement is due to the modified allocator's
|
||
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 allocator's
|
||
performance for certain types of workloads.
|
||
|
||
The micro benchmarks, which are crafted to emphasize memory read operations, highlight the
|
||
allocator's strengths. These tests simulate frequent and intensive memory access patterns,
|
||
where the reduction in TLB misses directly translates into measurable performance gains.
|
||
On average, the FAT allocator achieves a 50\% reduction in wall clock runtimes for
|
||
these workloads, underscoring its ability to optimize 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, diluting the impact of the allocator's optimizations. 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 to evaluate the performance difference
|
||
between the FAT allocator and Jemalloc as the workload scales. This analysis
|
||
aims to understand how the allocator's optimizations, 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 allocator's 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 allocator's ability to minimize 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 2000, 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 allocator's
|
||
optimizations.
|
||
|
||
% 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 demonstrates significant potential for enhancing
|
||
memory management in systems that benefit from huge page optimizations. Its design
|
||
effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
|
||
and TLB refills compared to 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-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 allocator's interaction with system-level caching and memory translation mechanisms.
|
||
|
||
While the allocator excels in scenarios emphasizing 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 those constrained by
|
||
computation or I/O bottlenecks.
|
||
|
||
% \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 addresses the growing disparity between application workloads and the capacity of TLBs.
|
||
To mitigate this gap, we proposed leveraging physically contiguous memory with CHERI bounds to reduce TLB walks.
|
||
We designed a memory allocator which uses huge pages with CHERI CC scheme to track allocations within the
|
||
allocated huge page. This approach reduces the number of TLB entries needed while using bounds
|
||
to minimize 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 demonstrate that the allocator reduces TLB misses by up to 90\%,
|
||
leading to substantial performance gains in memory-intensive workloads, though the improvements are less pronounced
|
||
for larger, computation-heavy applications. These results highlight the allocator's 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{unsrt}
|
||
\bibliography{paperReferences}
|
||
|
||
\end{document}
|
||
\endinput
|
||
%%
|
||
%% End of file `sample-sigconf-authordraft.tex'.
|
||
|