Cheri-research/FAT-Allocator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

saving changes commits added

Browse Source
This commit is contained in:
Akilan Selvacoumar
2025-04-21 09:35:55 +01:00
parent 8fda50a0f1
commit ab354efb68
6 changed files with 158 additions and 165 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/EuroSys/Paper/paper.aux
View File

@@ -64,8 +64,8 @@
\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Experiment setup}{5}{subsection.5.1}\protected@file@percent }
\newlabel{sec:Experiment}{{5.1}{5}{Experiment setup}{subsection.5.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Benchmarks}{5}{subsection.5.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Micro benchmark}{5}{subsubsection.5.2.1}\protected@file@percent }
\newlabel{sec:Micro}{{5.2.1}{5}{Micro benchmark}{subsubsection.5.2.1}{}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Micro benchmark}{5}{subsubsection.5.2.1}\protected@file@percent }
\newlabel{sec:Macro}{{5.2.2}{5}{Macro benchmark}{subsubsection.5.2.2}{}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.2}Macro benchmark}{5}{subsubsection.5.2.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Results}{6}{subsection.5.3}\protected@file@percent }

14
docs/EuroSys/Paper/paper.fdb_latexmk
View File

@@ -1,13 +1,13 @@
# Fdb version 4
["bibtex paper"] 1745154910.17453 "paper.aux" "paper.bbl" "paper" 1745154911.75342 0
["bibtex paper"] 1745224532.08591 "paper.aux" "paper.bbl" "paper" 1745224533.70736 0
"./paperReferences.bib" 1745154876.64218 46828 b3c7e70331098da6a7fbd68e2a4277a3 ""
"/usr/local/texlive/2025/texmf-dist/bibtex/bst/base/unsrt.bst" 1292289607 18030 1376b4b231b50c66211e47e42eda2875 ""
"paper.aux" 1745154911.45033 7767 2d2fd3c4d1929deee7aebd01524eab86 "pdflatex"
"paper.aux" 1745224533.40044 7767 c3c79e09db5ac00f42873e8ffbd9b68a "pdflatex"
(generated)
"paper.bbl"
"paper.blg"
(rewritten before read)
["pdflatex"] 1745154910.25767 "paper.tex" "paper.pdf" "paper" 1745154911.75354 0
["pdflatex"] 1745224532.17335 "paper.tex" "paper.pdf" "paper" 1745224533.70749 0
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc" 1558214095 7693 0f2dce6d313c82989ec3a67fc24df2a0 ""
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_25tcsq.enc" 1490131464 2921 8ca0eb0831f9bc5da080d3697cfe67bf ""
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_76gpa5.enc" 1490131464 2933 9ad527ce78d7c5fa0a642dead095f172 ""
@@ -219,10 +219,10 @@
"diagram/TLBAccess.drawio.png" 1744196148.80543 77522 75367f218335fe386db852966a892e9b ""
"diagram/bargraph.png" 1744196148.80607 74263 65509d21744edc6c9ca02b8c67d664fb ""
"diagram/kmeans.png" 1744196148.80901 94217 5d14308c169ff296bf499805b9823aa6 ""
"paper.aux" 1745154911.45033 7767 2d2fd3c4d1929deee7aebd01524eab86 "pdflatex"
"paper.bbl" 1745154910.25468 4124 00c91189ca7ebb5f2c50a354246b9795 "bibtex paper"
"paper.out" 1745154911.45126 3243 8666c5d883f1c403037236be395fbf0f "pdflatex"
"paper.tex" 1745154895.44511 84391 d1ac283cc14bbae16162b54e4807a57b ""
"paper.aux" 1745224533.40044 7767 c3c79e09db5ac00f42873e8ffbd9b68a "pdflatex"
"paper.bbl" 1745224532.17051 4124 00c91189ca7ebb5f2c50a354246b9795 "bibtex paper"
"paper.out" 1745224533.40129 3243 8666c5d883f1c403037236be395fbf0f "pdflatex"
"paper.tex" 1745224518.39528 84132 33b106b0947466adbb9bc7c72ae34180 ""
(generated)
"paper.aux"
"paper.log"

142
docs/EuroSys/Paper/paper.log
View File

@@ -1,4 +1,4 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 20 APR 2025 14:15
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 21 APR 2025 09:35
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@@ -1207,64 +1207,61 @@ LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 9.0pt on input line 359.
Underfull \vbox (badness 4913) has occurred while \output is active []
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 6.0pt on input line 394.
(Font) scaled to size 6.0pt on input line 391.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
LaTeX Font Info: Calculating math sizes for size <36.135> on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Calculating math sizes for size <36.135> on input line 391.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 36.135pt on input line 394.
(Font) scaled to size 36.135pt on input line 391.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 26.37839pt on input line 394.
(Font) scaled to size 26.37839pt on input line 391.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 19.87434pt on input line 394.
(Font) scaled to size 19.87434pt on input line 391.
[1.1{/usr/local/texlive/2025/texmf-var/fonts/map/pdftex/updmap/pdftex.map}{/usr
/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_76gpa5.enc}{/usr/
local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_25tcsq.enc}{/usr/l
@@ -1278,42 +1275,42 @@ ocal/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_naooyc.enc}
File: diagram/HighOverviewArchitecture.drawio.png Graphic file (type png)
<use diagram/HighOverviewArchitecture.drawio.png>
Package pdftex.def Info: diagram/HighOverviewArchitecture.drawio.png used on i
nput line 514.
nput line 511.
(pdftex.def) Requested size: 303.78008pt x 236.93262pt.
Class acmart Warning: A possible image without description on input line 518.
Class acmart Warning: A possible image without description on input line 515.
LaTeX Warning: `h' float specifier changed to `ht'.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 520.
(Font) scaled to size 9.0pt on input line 517.
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 9.0pt on input line 526.
(Font) scaled to size 9.0pt on input line 523.
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 7.0pt on input line 526.
(Font) scaled to size 7.0pt on input line 523.
[2.2]
<diagram/AllocationOverview24.png, id=141, 723.70375pt x 501.875pt>
File: diagram/AllocationOverview24.png Graphic file (type png)
<use diagram/AllocationOverview24.png>
Package pdftex.def Info: diagram/AllocationOverview24.png used on input line 5
43.
40.
(pdftex.def) Requested size: 202.51491pt x 140.43979pt.
Class acmart Warning: A possible image without description on input line 546.
Class acmart Warning: A possible image without description on input line 543.
<diagram/TLBAccess.drawio.png, id=146, 773.89125pt x 945.5325pt>
File: diagram/TLBAccess.drawio.png Graphic file (type png)
<use diagram/TLBAccess.drawio.png>
Package pdftex.def Info: diagram/TLBAccess.drawio.png used on input line 619.
Package pdftex.def Info: diagram/TLBAccess.drawio.png used on input line 616.
(pdftex.def) Requested size: 202.51491pt x 247.43411pt.
Class acmart Warning: A possible image without description on input line 622.
Class acmart Warning: A possible image without description on input line 619.
Underfull \vbox (badness 10000) has occurred while \output is active []
@@ -1323,13 +1320,13 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
[3.3 <./diagram/HighOverviewArchitecture.drawio.png> <./diagram/AllocationOverv
iew24.png>]
Package hyperref Info: bookmark level for unknown algorithm defaults to 0 on in
put line 675.
put line 672.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/sc' will be
(Font) scaled to size 9.0pt on input line 678.
(Font) scaled to size 9.0pt on input line 675.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 6.6pt on input line 679.
(Font) scaled to size 6.6pt on input line 676.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 5.5pt on input line 679.
(Font) scaled to size 5.5pt on input line 676.
@@ -1337,22 +1334,22 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
[4.4{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_ncsllp.e
nc}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_oexx6f.en
c} <./diagram/TLBAccess.drawio.png>]
Overfull \hbox (2.40372pt too wide) in paragraph at lines 753--757
\T1/LinuxLibertineT-TLF/m/n/9 (-20) loc [[]], Je-mal-loc is the de-fault mem-or
y al-lo-ca-tor for CHERIBSD [[]],
Overfull \hbox (2.01144pt too wide) in paragraph at lines 750--753
\T1/LinuxLibertineT-TLF/m/n/9 (-20) loc [[]]. Je-mal-loc is the de-fault mem-or
y al-lo-ca-tor for CHERIBSD [[]].
[]
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 865.
LaTeX Font Info: Trying to load font information for T1+zi4 on input line 87
4.
(Font) scaled to size 9.0pt on input line 867.
LaTeX Font Info: Trying to load font information for T1+zi4 on input line 86
8.
(/usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd
File: t1zi4.fd 2018/01/14 T1/zi4 (Inconsolata)
)
LaTeX Font Info: Font shape `T1/zi4/m/n' will be
(Font) scaled to size 9.0pt on input line 874.
(Font) scaled to size 9.0pt on input line 868.
Package microtype Info: Loading generic protrusion settings for font family
(microtype) `zi4' (encoding: T1).
(microtype) For optimal results, create family-specific settings.
@@ -1360,20 +1357,22 @@ Package microtype Info: Loading generic protrusion settings for font family
<diagram/bargraph.png, id=182, 1156.32pt x 722.7pt>
File: diagram/bargraph.png Graphic file (type png)
<use diagram/bargraph.png>
Package pdftex.def Info: diagram/bargraph.png used on input line 917.
Package pdftex.def Info: diagram/bargraph.png used on input line 911.
(pdftex.def) Requested size: 455.6624pt x 284.78517pt.
Class acmart Warning: A possible image without description on input line 919.
Class acmart Warning: A possible image without description on input line 913.
LaTeX Warning: `h' float specifier changed to `ht'.
Underfull \vbox (badness 2088) has occurred while \output is active []
[5.5{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc
}]
LaTeX Warning: `h' float specifier changed to `ht'.
Underfull \vbox (badness 10000) has occurred while \output is active []
@@ -1387,15 +1386,18 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
<./diagram/kmeans.png, id=207, 1011.78pt x 578.16pt>
File: ./diagram/kmeans.png Graphic file (type png)
<use ./diagram/kmeans.png>
Package pdftex.def Info: ./diagram/kmeans.png used on input line 967.
Package pdftex.def Info: ./diagram/kmeans.png used on input line 961.
(pdftex.def) Requested size: 265.2637pt x 151.57959pt.
Overfull \hbox (24.11621pt too wide) in paragraph at lines 967--968
Overfull \hbox (24.11621pt too wide) in paragraph at lines 961--962
[][]
[]
Class acmart Warning: A possible image without description on input line 969.
Class acmart Warning: A possible image without description on input line 963.
Underfull \vbox (badness 2096) has occurred while \output is active []
@@ -1404,13 +1406,7 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
[7.7 <./diagram/bargraph.png> <./diagram/kmeans.png>]
Overfull \hbox (1.25471pt too wide) in paragraph at lines 1013--1017
[]\T1/LinuxLibertineT-TLF/m/n/9 (-20) While the al-lo-ca-tor ex-cels in sce-nar
-ios em-pha-siz-ing high-memory
[]
(./paper.bbl
[7.7 <./diagram/bargraph.png> <./diagram/kmeans.png>] (./paper.bbl
Underfull \hbox (badness 2443) in paragraph at lines 91--93
@@ -1449,13 +1445,13 @@ Package rerunfilecheck Info: File `paper.out' has not changed.
(rerunfilecheck) Checksum: 8666C5D883F1C403037236BE395FBF0F;3243.
)
Here is how much of TeX's memory you used:
24052 strings out of 473190
394523 string characters out of 5715801
967612 words of memory out of 5000000
24043 strings out of 473190
394298 string characters out of 5715801
968614 words of memory out of 5000000
46201 multiletter control sequences out of 15000+600000
776962 words of font info for 460 fonts, out of 8000000 for 9000
775822 words of font info for 454 fonts, out of 8000000 for 9000
1302 hyphenation exceptions out of 8191
90i,17n,131p,1002b,645s stack positions out of 10000i,1000n,20000p,200000b,200000s
90i,16n,131p,1002b,645s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/local/texlive/2025/texmf-dist/fonts/type1/public/inconsolata/Inconsolat
a-zi4r.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/newtx/Liberti
neMathMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/libertine/L
@@ -1467,7 +1463,7 @@ lic/libertine/LinLibertineTB.pfb></usr/local/texlive/2025/texmf-dist/fonts/type
1/public/libertine/LinLibertineTI.pfb></usr/local/texlive/2025/texmf-dist/fonts
/type1/public/newtx/NewTXMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1
/public/newtx/txsys.pfb>
Output written on paper.pdf (8 pages, 710830 bytes).
Output written on paper.pdf (8 pages, 710646 bytes).
PDF statistics:
293 PDF objects out of 1000 (max. 8388607)
244 compressed objects within 3 object streams

BIN
docs/EuroSys/Paper/paper.pdf
View File

Binary file not shown.

164
docs/EuroSys/Paper/paper.tex
View File

@@ -368,7 +368,7 @@ memory allocations. The contributions for the following paper are as follows:
(Section ~\ref{sec:MemoryAllocator}).
\end{itemize}
Through comprehensive evaluation including micro and macro benchmarks, we demonstrate the allocator's ability
Through comprehensive evaluation including micro and macro benchmarks, we demonstrate the allocators ability
to reduce TLB misses by up to 90\% which yields in significant improvements in wall clock runtimes 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
@@ -434,10 +434,10 @@ 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 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.
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{CHERI}
\label{sec:orgbf2eaac}
@@ -460,18 +460,17 @@ 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 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 compartmentalisation; 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
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 Concentrate: Practical Compressed Capabilities\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI, aims to address the performance and compatibility challenges associated with
CHERI Concentrate: Practical 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, but traditional implementations double their size—leading to increased memory usage. CHERI CC
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.
@@ -515,12 +514,12 @@ in this implementation is the use of range addresses with CHERI CC~\cite{woodruf
% \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
Figure \ref{fig:HighOverviewArchitecture} illustrates a 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 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.
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
@@ -552,11 +551,11 @@ 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
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 the FAT, ensuring tracking of the allocated memory regions.
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.
\subsection{128 bit compressed bounds}
@@ -655,12 +654,12 @@ on physically contiguous memory.
\section{Memory allocator design}
\label{sec:MemoryAllocator}
This section presents a straightforward memory allocator designed and implemented based on the
This section presents a straightforward memory allocator designed and 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, while the \textit{free}
function deallocates the memory, returning it to the pool for future use.
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
@@ -684,15 +683,15 @@ function deallocates the memory, returning it to the pool for future use.
\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-specialised
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, enabling efficient monitoring and management of memory usage.
explicitly encoded in the address which enables 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
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.
@@ -709,8 +708,8 @@ efficient memory management but also demonstrate a practical use case of huge pa
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
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.
@@ -738,27 +737,26 @@ efficient memory management but also demonstrate a practical use case of huge pa
\end{algorithmic}
\end{algorithm}
Algorithm \ref{alg:initAlloc} describes the initialisation of physically contiguous memory through the use of huge pages,
a mechanism supported by modern architectures to optimise 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
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 efficiency, which is critical for performance-sensitive
with page table management and enhances memory access. 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
We conducted tests of the FAT memory allocator against Jemalloc~\cite{jemalloc}.
Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}. We evaluated
the reduction in TLB walks and misses and its impact on wall clock runtime.
To comprehensively analyse the proposed allocator, we categorised 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.
C programs designed to target specific allocator patterns 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
@@ -789,7 +787,7 @@ performance in more practical, real-world scenarios.
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
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 was
used as recommended by the CHERI community. This compilation mode was enabled using
the Clang compiler.
@@ -798,19 +796,19 @@ The Benchmark ABI~\cite{BenchmarkABI} was specifically designed because the More
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.
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,
the modified C allocator 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.
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
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.
@@ -857,28 +855,26 @@ the proposed changes.
\end{table*}
\subsection{Benchmarks}
The benchmarks~\cite{Benchmark} are classified into 2 classes:
We elaborate here on the two classes of benchmarks~\cite{Benchmark}. Micro benchmarks (Section~\ref{sec:Micro}).
focused on particular allocation and 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}
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
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 by Alex Bordei evaluates the performance impact of
\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, optional node operations, and multithreaded
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}
@@ -888,18 +884,18 @@ and varying execution contexts.
\begin{itemize}
\item \texttt{Kmeans}: Kmeans implements a parallelised K-means clustering algorithm that
assigns data points to clusters based on proximity to centroids,
iteratively updating them until convergence. The computation is
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
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,
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.
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}. The implementation we benchmark extends the original method by permitting multiple
@@ -917,8 +913,8 @@ This extension is described by Holt and Singh ~\cite{holt1995}.
\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 optimised
for use with huge pages, demonstrates a clear advantage in scenarios where memory allocation
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.
@@ -940,23 +936,23 @@ of its capability to handle memory more efficiently by leveraging huge pages.
\end{itemize}
A particularly striking observation is the significant reduction in data TLB walks,
L2 data TLB reads, and TLB refills-consistently show a 90\% decrease across all
benchmarks compared to Jemalloc. This improvement is due to the modified allocator's
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 allocator's
largely eliminated. This reduction in translation overhead is a key factor in the allocators
performance for certain types of workloads.
The microbenchmarks, which are crafted to emphasize memory read operations, highlight the
allocator's strengths. These tests simulate frequent and intensive memory access patterns,
The microbenchmarks 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.
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 ,
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 optimisations. Additionally,
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.
@@ -968,22 +964,22 @@ bottlenecked by factors such as computation or I/O rather than memory translatio
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 optimisations, particularly its ability to manage memory
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 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 minimise TLB misses
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 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
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
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
@@ -1000,15 +996,15 @@ The FAT memory allocator 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 Jemalloc. These improvements lead to noticeable performance
gains, especially in micro benchmarks, where the allocator reduces wall clock runtimes
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
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.
insights into the allocators interaction with system-level caching and memory translation mechanisms.
While the allocator excels in scenarios emphasizing high-memory throughput, its impact on
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 those constrained by
computation or I/O bottlenecks.
@@ -1048,7 +1044,7 @@ to minimise fragmentation.
\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
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.

1
docs/EuroSys/Paper/track.txt Normal file
View File

@@ -0,0 +1 @@
RMM