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

saving current changes

Browse Source
This commit is contained in:
Akilan Selvacoumar
2025-07-11 00:20:58 +01:00
parent a102498d86
commit 4ec5e6da4c
26 changed files with 1034 additions and 381 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/EuroSys/.DS_Store vendored
View File

Binary file not shown.

13
docs/EuroSys/Paper/email.org Normal file
View File

@@ -0,0 +1,13 @@
** Discussion with Adam:
Recommendation to adding a few pages to the thesis mentioning that Security is not the goal of the current research.
- To mention aspects such as timing attacks was not evaluated.
- When storing bounds next to each other attacks such hammering DRAM to cause bitflips (Rowhammer attack) is a possibility.
We spoke in detail about the use case of Libc against Kernel modules. He asked me why contig malloc was not used to which I mentioned the underlying behavior of it.
Adam recommended for the evaluation section to have scatter plot show casing the numbers for multiple runs (This is a bit tricky in our case since we are doing a percentage difference).
- We spoke about the performance runs in detail. For instance what ARM counters are missing from the Morello implementation and how we used to the other performance counters to cover them.
- We spoke about the wide use of Jemalloc but the lack of Academic sources to the Jemalloc implementation. It was good to know as someone working in performance side and Adam coming from the Security side we both faced similar rabbit holes when it came to dealing with finding academic algorithmic references to Jemalloc.
- Adam understood my reasoning on why I could not make certain trivial assumptions about cache misses with Jemalloc with Contigious memory vs Standard Jemalloc. He recommended that the Thesis should have this (Appreciated that these aspects are considered).
In regards to the timetable he mentioned that it's a good decision sticking to the RISCV simulator and not focusing on the Uni-kernel experiment. He recommended that to keep slippage time until max February or March 2026 as a hard deadline for experiments (But motivated to finish them by December).

18
docs/EuroSys/Paper/email.org~ Normal file
View File

@@ -0,0 +1,18 @@
Hi Rob and all,
Here is the summary of the meeting with Adam:
Overall it went very well.
Discussion with Adam:
Recommendation to adding a few pages to the thesis mentioning that Security is not the goal of the current research.
- To mention aspects such as timing attacks was not evaluated.
- When storing bounds next to each other attacks such hammering DRAM to cause bitflips (Row hammer attack) is a possibility.
We spoke in detail about the use case of Libc against Kernel modules. He asked me why contig malloc was not used to which I mentioned the underlying behavior of it.
Adam recommended for the evaluation section to have scatter plot show casing the numbers for multiple runs (This is a bit tricky in our case since we are doing a percentage difference).
- We spoke about the performance runs in detail. For instance what ARM counters are missing from the Morello implementation and how we used to the other performance counters to cover them.
- We spoke about the wide use of Jemalloc but the lack of Academic sources to the Jemalloc implementation. It was good to know as someone working in performance side and Adam coming from the Security side we both faced similar rabbit holes when it came to dealing with finding academic algorithmic references to Jemalloc.
- Adam understood my reasoning on why I could not make certain trivial assumptions about cache misses with Jemalloc with Contigious memory vs Standard Jemalloc. He recommended that the Thesis should have this (Appreciated that these aspects are considered).
In regards to the timetable he mentioned that it's a good decision sticking to the RISCV simulator and not focusing on the Uni-kernel experiment. He recommended that to keep slippage time until max February or March 2026 as a hard deadline for experiments (But motivated to finish them by December).

BIN
docs/EuroSys/Paper/email.pdf Normal file
View File

Binary file not shown.

49
docs/EuroSys/Paper/email.tex Normal file
View File

@@ -0,0 +1,49 @@
% Created 2025-06-30 Mon 16:42
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Akilan}
\date{\today}
\title{}
\hypersetup{
pdfauthor={Akilan},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 30.1 (Org mode 9.7.11)},
pdflang={English}}
\begin{document}
\tableofcontents
\section{Discussion with Adam:}
\label{sec:org9f7a2c6}
Recommendation to adding a few pages to the thesis mentioning that Security is not the goal of the current research.
\begin{itemize}
\item To mention aspects such as timing attacks was not evaluated.
\begin{itemize}
\item When storing bounds next to each other attacks such hammering DRAM to cause bitflips (Rowhammer attack) is a possibility.
\end{itemize}
\end{itemize}
We spoke in detail about the use case of Libc against Kernel modules. He asked me why contig malloc was not used to which I mentioned the underlying behavior of it.
Adam recommended for the evaluation section to have scatter plot show casing the numbers for multiple runs (This is a bit tricky in our case since we are doing a percentage difference).
\begin{itemize}
\item We spoke about the performance runs in detail. For instance what ARM counters are missing from the Morello implementation and how we used to the other performance counters to cover them.
\item We spoke about the wide use of Jemalloc but the lack of Academic sources to the Jemalloc implementation. It was good to know as someone working in performance side and Adam coming from the Security side we both faced similar rabbit holes when it came to dealing with finding academic algorithmic references to Jemalloc.
\item Adam understood my reasoning on why I could not make certain trivial assumptions about cache misses with Jemalloc with Contigious memory vs Standard Jemalloc. He recommended that the Thesis should have this (Appreciated that these aspects are considered).
\end{itemize}
In regards to the timetable he mentioned that it's a good decision sticking to the RISCV simulator and not focusing on the Uni-kernel experiment. He recommended that to keep slippage time until max February or March 2026 as a hard deadline for experiments (But motivated to finish them by December).
\end{document}

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

@@ -44,6 +44,7 @@
\@writefile{toc}{\contentsline {section}{\numberline {4}128 bit compressed bounds}{3}{section.4}\protected@file@percent }
\newlabel{sec:128bitCompressedBounds}{{4}{3}{128 bit compressed bounds}{section.4}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Instrumenting Block-Based Allocators with Physically Contiguous Memory}{3}{subsection.4.1}\protected@file@percent }
\citation{CheriABI}
\citation{evans_scalable_nodate}
\@writefile{toc}{\contentsline {section}{\numberline {5}Memory allocator design}{4}{section.5}\protected@file@percent }
\newlabel{sec:MemoryAllocator}{{5}{4}{Memory allocator design}{section.5}{}}
@@ -67,7 +68,7 @@
\newlabel{alg:JemallocMalloc}{{4}{5}{Modified Jemalloc Memory Mapping Routines}{algorithm.4}{}}
\@writefile{loa}{\contentsline {algorithm}{\numberline {5}{\ignorespaces os\_pages\_unmap}}{5}{algorithm.5}\protected@file@percent }
\newlabel{alg:JemallocFree}{{5}{5}{os\_pages\_unmap}{algorithm.5}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Mumap replaced with FREE}{5}{subsection.6.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Munmap replaced with FREE}{5}{subsection.6.2}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {7}Evaluation}{5}{section.7}\protected@file@percent }
\newlabel{sec:Evaluation}{{7}{5}{Evaluation}{section.7}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Experiment setup}{5}{subsection.7.1}\protected@file@percent }
@@ -82,8 +83,8 @@
\newlabel{table:ARMPerf}{{1}{6}{ARM performance counters}{table.caption.4}{}}
\citation{singh1993}
\citation{holt1995}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results}{7}{subsection.7.3}\protected@file@percent }
\newlabel{sec:Results}{{7.3}{7}{Results}{subsection.7.3}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results and discussion}{7}{subsection.7.3}\protected@file@percent }
\newlabel{sec:Results}{{7.3}{7}{Results and discussion}{subsection.7.3}{}}
\newlabel{fig:dtlb-walk}{{2a}{8}{DTLB Walks}{figure.caption.5}{}}
\newlabel{sub@fig:dtlb-walk}{{a}{8}{DTLB Walks}{figure.caption.5}{}}
\newlabel{fig:l1tlb-reads}{{2b}{8}{L1 TLB Reads}{figure.caption.5}{}}
@@ -98,8 +99,6 @@
\newlabel{sub@fig:wallclock}{{f}{8}{Wall Clock Time}{figure.caption.5}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Benchmarks comparing the percentage difference between FAT.}}{8}{figure.caption.5}\protected@file@percent }
\newlabel{fig:benchmarks-group}{{2}{8}{Benchmarks comparing the percentage difference between FAT}{figure.caption.5}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Analysis}{8}{subsection.7.4}\protected@file@percent }
\newlabel{sec:Analysis}{{7.4}{8}{Analysis}{subsection.7.4}{}}
\bibstyle{unsrtnat}
\bibdata{paperReferences}
\bibcite{TLBHierarchy}{{1}{2013}{{Lustig et~al.}}{{Lustig, Bhattacharjee, and Martonosi}}}
@@ -114,15 +113,16 @@
\bibcite{DirectSegment}{{10}{2013}{{Basu et~al.}}{{Basu, Gandhi, Chang, Hill, and Swift}}}
\bibcite{karakostas_redundant_2015}{{11}{}{{Karakostas et~al.}}{{Karakostas, Gandhi, Ayar, Cristal, Hill, {McKinley}, Nemirovsky, Swift, and Ünsal}}}
\bibcite{chen_flexpointer_2023}{{12}{2023}{{Chen et~al.}}{{Chen, Tong, Yang, Yi, and Cheng}}}
\bibcite{evans_scalable_nodate}{{13}{}{{Evans}}{{}}}
\bibcite{jemalloc}{{14}{2006}{{Evans}}{{}}}
\bibcite{cheribsd}{{15}{}{{che}}{{}}}
\bibcite{Benchmark}{{16}{}{{Ben}}{{}}}
\bibcite{Morello}{{17}{}{{Mor}}{{}}}
\bibcite{BenchmarkABI}{{18}{2023}{{Watson et~al.}}{{Watson, Clarke, Sewell, Woodruff, Moore, Barnes, Grisenthwaite, Stacer, Baranga, and Richardson}}}
\bibcite{PerformanceCounter}{{19}{}{{Per}}{{}}}
\bibcite{singh1993}{{20}{1993}{{Singh}}{{}}}
\bibcite{holt1995}{{21}{1995}{{Holt and Singh}}{{}}}
\bibcite{CheriABI}{{13}{2019}{{Davis et~al.}}{{Davis, Watson, Richardson, Neumann, Moore, Baldwin, Chisnall, Clarke, Filardo, Gudka, Joannou, Laurie, Markettos, Maste, Mazzinghi, Napierala, Norton, Roe, Sewell, Son, and Woodruff}}}
\bibcite{evans_scalable_nodate}{{14}{}{{Evans}}{{}}}
\bibcite{jemalloc}{{15}{2006}{{Evans}}{{}}}
\bibcite{cheribsd}{{16}{}{{che}}{{}}}
\bibcite{Benchmark}{{17}{}{{Ben}}{{}}}
\bibcite{Morello}{{18}{}{{Mor}}{{}}}
\bibcite{BenchmarkABI}{{19}{2023}{{Watson et~al.}}{{Watson, Clarke, Sewell, Woodruff, Moore, Barnes, Grisenthwaite, Stacer, Baranga, and Richardson}}}
\bibcite{PerformanceCounter}{{20}{}{{Per}}{{}}}
\bibcite{singh1993}{{21}{1993}{{Singh}}{{}}}
\bibcite{holt1995}{{22}{1995}{{Holt and Singh}}{{}}}
\newlabel{tocindent-1}{0pt}
\newlabel{tocindent0}{0pt}
\newlabel{tocindent1}{4.185pt}

21
docs/EuroSys/Paper/paper.bbl
View File

@@ -1,4 +1,4 @@
\begin{thebibliography}{21}
\begin{thebibliography}{22}
\providecommand{\natexlab}[1]{#1}
\providecommand{\url}[1]{\texttt{#1}}
\expandafter\ifx\csname urlstyle\endcsname\relax
@@ -127,6 +127,25 @@ Dongwei Chen, Dong Tong, Chun Yang, Jiangfang Yi, and Xu~Cheng.
\newblock \doi{10.1145/3579854}.
\newblock URL \url{https://doi.org/10.1145/3579854}.
\bibitem[Davis et~al.(2019)Davis, Watson, Richardson, Neumann, Moore, Baldwin,
Chisnall, Clarke, Filardo, Gudka, Joannou, Laurie, Markettos, Maste,
Mazzinghi, Napierala, Norton, Roe, Sewell, Son, and Woodruff]{CheriABI}
Brooks Davis, Robert N.~M. Watson, Alexander Richardson, Peter~G. Neumann,
Simon~W. Moore, John Baldwin, David Chisnall, Jessica Clarke,
Nathaniel~Wesley Filardo, Khilan Gudka, Alexandre Joannou, Ben Laurie,
A.~Theodore Markettos, J.~Edward Maste, Alfredo Mazzinghi, Edward~Tomasz
Napierala, Robert~M. Norton, Michael Roe, Peter Sewell, Stacey Son, and
Jonathan Woodruff.
\newblock Cheriabi: Enforcing valid pointer provenance and minimizing pointer
privilege in the posix c run-time environment.
\newblock In \emph{Proceedings of the Twenty-Fourth International Conference on
Architectural Support for Programming Languages and Operating Systems},
ASPLOS '19, page 379–393, New York, NY, USA, 2019. Association for
Computing Machinery.
\newblock ISBN 9781450362405.
\newblock \doi{10.1145/3297858.3304042}.
\newblock URL \url{https://doi.org/10.1145/3297858.3304042}.
\bibitem[Evans()]{evans_scalable_nodate}
Jason Evans.
\newblock A {Scalable} {Concurrent} malloc(3) {Implementation} for {FreeBSD}.

64
docs/EuroSys/Paper/paper.blg
View File

@@ -29,45 +29,45 @@ Warning--empty year in cheribsd
Warning--empty year in Benchmark
Warning--empty year in Morello
Warning--empty year in PerformanceCounter
You've used 21 entries,
You've used 22 entries,
2481 wiz_defined-function locations,
702 strings with 9994 characters,
and the built_in function-call counts, 8880 in all, are:
= -- 740
> -- 511
< -- 11
+ -- 199
- -- 156
* -- 757
:= -- 1413
add.period$ -- 97
call.type$ -- 21
change.case$ -- 41
chr.to.int$ -- 20
cite$ -- 43
duplicate$ -- 424
empty$ -- 756
format.name$ -- 177
if$ -- 1887
712 strings with 10668 characters,
and the built_in function-call counts, 9955 in all, are:
= -- 808
> -- 640
< -- 12
+ -- 243
- -- 198
* -- 864
:= -- 1602
add.period$ -- 104
call.type$ -- 22
change.case$ -- 43
chr.to.int$ -- 21
cite$ -- 44
duplicate$ -- 465
empty$ -- 802
format.name$ -- 220
if$ -- 2109
int.to.chr$ -- 2
int.to.str$ -- 22
missing$ -- 15
newline$ -- 144
num.names$ -- 51
pop$ -- 186
int.to.str$ -- 23
missing$ -- 16
newline$ -- 152
num.names$ -- 54
pop$ -- 193
preamble$ -- 1
purify$ -- 21
purify$ -- 22
quote$ -- 0
skip$ -- 259
skip$ -- 295
stack$ -- 0
substring$ -- 285
swap$ -- 90
text.length$ -- 5
substring$ -- 305
swap$ -- 111
text.length$ -- 6
text.prefix$ -- 0
top$ -- 0
type$ -- 147
type$ -- 154
warning$ -- 18
while$ -- 51
while$ -- 54
width$ -- 0
write$ -- 330
write$ -- 352
(There were 22 warnings)

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

@@ -1,13 +1,13 @@
# Fdb version 4
["bibtex paper"] 1748909508.19157 "paper.aux" "paper.bbl" "paper" 1748915503.84679 0
"./paperReferences.bib" 1748637417.99093 52057 3d2940a76dd1a0b9b759a973d6b9bd98 ""
["bibtex paper"] 1750705998.27393 "paper.aux" "paper.bbl" "paper" 1750706000.11317 0
"./paperReferences.bib" 1750702099.74581 54714 19039cdfd8414d201259ef3610c2b156 ""
"/usr/local/texlive/2025/texmf-dist/bibtex/bst/natbib/unsrtnat.bst" 1233624470 24550 a41a6405f4de768c43e871d9fbce2bc8 ""
"paper.aux" 1748915503.46464 9963 82b0905dd9ab54680dce426b8abf6c10 "pdflatex"
"paper.aux" 1750705999.79329 10069 17bcbc579b981872002f8e9b5c2e2978 "pdflatex"
(generated)
"paper.bbl"
"paper.blg"
(rewritten before read)
["pdflatex"] 1748915501.92795 "paper.tex" "paper.pdf" "paper" 1748915503.84693 0
["pdflatex"] 1750705998.36154 "paper.tex" "paper.pdf" "paper" 1750706000.1133 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 ""
@@ -228,10 +228,10 @@
"diagram/benchmarks-group/bargraph-large-ll-cache-rd.png" 1747839169.49301 52855 22a83d7bc1ca7dfa1c47f31936824ff6 ""
"diagram/benchmarks-group/bargraph-large-wallclock.png" 1747839751.63939 55378 1da56901d20a39a645beca6272b36eaf ""
"diagram/drawing.pdf" 1748909319.05561 28646 0eb4d6c5fd7bfd13117f881769bcc40b ""
"paper.aux" 1748915503.46464 9963 82b0905dd9ab54680dce426b8abf6c10 "pdflatex"
"paper.bbl" 1748909508.27529 8553 1083156a0ae40396808b10750dbef288 "bibtex paper"
"paper.out" 1748915503.46551 4043 e0a4be03bd5f2bf273294833454e3065 "pdflatex"
"paper.tex" 1748915020.18884 105736 8bdc0702db90478ee04e1eec63cfe7dd ""
"paper.aux" 1750705999.79329 10069 17bcbc579b981872002f8e9b5c2e2978 "pdflatex"
"paper.bbl" 1750705998.3586 9667 69909f93a1ff23493346e23e89c1311f "bibtex paper"
"paper.out" 1750705999.79419 4008 21fd7693a5a3059545203aa7db2ea238 "pdflatex"
"paper.tex" 1750705972.02315 109620 7c35b92413acedf60b17b8595a2bf996 ""
(generated)
"paper.aux"
"paper.log"

283
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) 3 JUN 2025 02:51
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 23 JUN 2025 20:13
entering extended mode
\write18 enabled.
%&-line parsing enabled.
@@ -1109,52 +1109,52 @@ Package caption Info: listings package is loaded.
Package caption Info: End \AtBeginDocument code.
\c@lstlisting=\count367
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 17.28pt on input line 316.
(Font) scaled to size 17.28pt on input line 318.
LaTeX Font Info: Trying to load font information for T1+LinuxBiolinumT-TLF o
n input line 316.
n input line 318.
(/usr/local/texlive/2025/texmf-dist/tex/latex/libertine/T1LinuxBiolinumT-TLF.fd
File: T1LinuxBiolinumT-TLF.fd 2017/03/20 (autoinst) Font definitions for T1/Lin
uxBiolinumT-TLF.
)
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 17.28pt on input line 316.
(Font) scaled to size 17.28pt on input line 318.
Package microtype Info: Loading generic protrusion settings for font family
(microtype) `LinuxBiolinumT-TLF' (encoding: T1).
(microtype) For optimal results, create family-specific settings.
(microtype) See the microtype manual for details.
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/b/n' will be
(Font) scaled to size 17.28pt on input line 316.
(Font) scaled to size 17.28pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
Package microtype Info: Loading generic protrusion settings for font family
(microtype) `LinuxLibertineT-TLF' (encoding: OT1).
(microtype) For optimal results, create family-specific settings.
(microtype) See the microtype manual for details.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
(/usr/local/texlive/2025/texmf-dist/tex/latex/microtype/mt-msa.cfg
File: mt-msa.cfg 2006/02/04 v1.1 microtype config. file: AMS symbols (a) (RS)
)
@@ -1162,31 +1162,31 @@ File: mt-msa.cfg 2006/02/04 v1.1 microtype config. file: AMS symbols (a) (RS)
File: mt-msb.cfg 2005/06/01 v1.0 microtype config. file: AMS symbols (b) (RS)
)
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 12.0pt on input line 316.
(Font) scaled to size 12.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 6.6pt on input line 316.
(Font) scaled to size 6.6pt on input line 318.
LaTeX Font Info: Trying to load font information for TS1+LinuxLibertineT-TLF
on input line 316.
on input line 318.
(/usr/local/texlive/2025/texmf-dist/tex/latex/libertine/TS1LinuxLibertineT-TLF.
fd
@@ -1194,160 +1194,160 @@ File: TS1LinuxLibertineT-TLF.fd 2017/03/20 (autoinst) Font definitions for TS1/
LinuxLibertineT-TLF.
)
LaTeX Font Info: Font shape `TS1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 8.8pt on input line 316.
(Font) scaled to size 8.8pt on input line 318.
Package microtype Info: Loading generic protrusion settings for font family
(microtype) `LinuxLibertineT-TLF' (encoding: TS1).
(microtype) For optimal results, create family-specific settings.
(microtype) See the microtype manual for details.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/b/n' will be
(Font) scaled to size 10.0pt on input line 316.
(Font) scaled to size 10.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be
(Font) scaled to size 7.0pt on input line 316.
(Font) scaled to size 7.0pt on input line 318.
LaTeX Font Info: Font shape `TS1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 7.0pt on input line 316.
(Font) scaled to size 7.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/b/n' will be
(Font) scaled to size 9.0pt on input line 316.
(Font) scaled to size 9.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/b/n' will be
(Font) scaled to size 10.95pt on input line 316.
(Font) scaled to size 10.95pt on input line 318.
Overfull \hbox (8.2084pt too wide) in paragraph at lines 316--316
Overfull \hbox (8.2084pt too wide) in paragraph at lines 318--318
[]\T1/LinuxLibertineT-TLF/m/n/9 (-20) The con-tri-bu-tion is an al-ter-na-tive
ap-proach by ex-ploit-ing capability-
[]
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/b/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 8.0pt on input line 316.
(Font) scaled to size 8.0pt on input line 318.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 6.0pt on input line 316.
(Font) scaled to size 6.0pt on input line 318.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 9.0pt on input line 376.
(Font) scaled to size 9.0pt on input line 383.
Underfull \vbox (badness 10000) 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 389.
(Font) scaled to size 6.0pt on input line 396.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
LaTeX Font Info: Calculating math sizes for size <36.135> on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Calculating math sizes for size <36.135> on input line 396.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `U/ntxmia/m/it' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsym/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 36.135pt on input line 389.
(Font) scaled to size 36.135pt on input line 396.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 26.37839pt on input line 389.
(Font) scaled to size 26.37839pt on input line 396.
LaTeX Font Info: Font shape `U/ntxexa/m/n' will be
(Font) scaled to size 19.87434pt on input line 389.
(Font) scaled to size 19.87434pt on input line 396.
[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
@@ -1357,53 +1357,50 @@ ocal/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_naooyc.enc}
/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_7grukw.enc}]
LaTeX Font Info: Font shape `TS1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 9.0pt on input line 468.
(Font) scaled to size 9.0pt on input line 475.
Underfull \vbox (badness 1895) has occurred while \output is active []
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 9.0pt on input line 498.
(Font) scaled to size 9.0pt on input line 510.
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 7.0pt on input line 498.
(Font) scaled to size 7.0pt on input line 510.
[2.2]
<diagram/drawing.pdf, id=158, 459.57687pt x 430.33751pt>
<diagram/drawing.pdf, id=154, 459.57687pt x 430.33751pt>
File: diagram/drawing.pdf Graphic file (type pdf)
<use diagram/drawing.pdf>
Package pdftex.def Info: diagram/drawing.pdf used on input line 548.
Package pdftex.def Info: diagram/drawing.pdf used on input line 560.
(pdftex.def) Requested size: 192.91872pt x 180.64859pt.
Class acmart Warning: A possible image without description on input line 551.
Class acmart Warning: A possible image without description on input line 563.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 611.
Underfull \vbox (badness 1270) has occurred while \output is active []
(Font) scaled to size 9.0pt on input line 623.
[3.3 <./diagram/drawing.pdf>]
Package hyperref Info: bookmark level for unknown algorithm defaults to 0 on in
put line 745.
put line 757.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/sc' will be
(Font) scaled to size 9.0pt on input line 748.
(Font) scaled to size 9.0pt on input line 760.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 6.6pt on input line 749.
(Font) scaled to size 6.6pt on input line 761.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 5.5pt on input line 749.
(Font) scaled to size 5.5pt on input line 761.
LaTeX Font Info: Trying to load font information for T1+zi4 on input line 83
4.
LaTeX Font Info: Trying to load font information for T1+zi4 on input line 84
6.
(/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 834.
(Font) scaled to size 9.0pt on input line 846.
Package microtype Info: Loading generic protrusion settings for font family
(microtype) `zi4' (encoding: T1).
(microtype) For optimal results, create family-specific settings.
@@ -1419,7 +1416,7 @@ c}]
[5.5{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc
}]
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 1061.
(Font) scaled to size 9.0pt on input line 1073.
@@ -1428,57 +1425,57 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
[6.6]
<diagram/benchmarks-group/bargraph-large-dtlb-walk.png, id=258, 1011.78pt x 578
<diagram/benchmarks-group/bargraph-large-dtlb-walk.png, id=256, 1011.78pt x 578
.16pt>
File: diagram/benchmarks-group/bargraph-large-dtlb-walk.png Graphic file (type
png)
<use diagram/benchmarks-group/bargraph-large-dtlb-walk.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-dtlb-walk.png
used on input line 1148.
used on input line 1160.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l1tlb-reads.png, id=260, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-l1tlb-reads.png, id=258, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-l1tlb-reads.png Graphic file (typ
e png)
<use diagram/benchmarks-group/bargraph-large-l1tlb-reads.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-reads.pn
g used on input line 1153.
g used on input line 1165.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l1tlb-refill.png, id=261, 1011.78pt x
<diagram/benchmarks-group/bargraph-large-l1tlb-refill.png, id=259, 1011.78pt x
578.16pt>
File: diagram/benchmarks-group/bargraph-large-l1tlb-refill.png Graphic file (ty
pe png)
<use diagram/benchmarks-group/bargraph-large-l1tlb-refill.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-refill.p
ng used on input line 1161.
ng used on input line 1173.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l2tlb-reads.png, id=262, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-l2tlb-reads.png, id=260, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-l2tlb-reads.png Graphic file (typ
e png)
<use diagram/benchmarks-group/bargraph-large-l2tlb-reads.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l2tlb-reads.pn
g used on input line 1166.
g used on input line 1178.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-ll-cache-rd.png, id=263, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-ll-cache-rd.png, id=261, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-ll-cache-rd.png Graphic file (typ
e png)
<use diagram/benchmarks-group/bargraph-large-ll-cache-rd.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-ll-cache-rd.pn
g used on input line 1174.
g used on input line 1186.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-wallclock.png, id=264, 1011.78pt x 578
<diagram/benchmarks-group/bargraph-large-wallclock.png, id=262, 1011.78pt x 578
.16pt>
File: diagram/benchmarks-group/bargraph-large-wallclock.png Graphic file (type
png)
<use diagram/benchmarks-group/bargraph-large-wallclock.png>
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-wallclock.png
used on input line 1179.
used on input line 1191.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
Class acmart Warning: A possible image without description on input line 1187.
Class acmart Warning: A possible image without description on input line 1199.
@@ -1504,7 +1501,7 @@ s.png> <./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png> <./diagram/b
enchmarks-group/bargraph-large-wallclock.png>] (./paper.bbl
Underfull \hbox (badness 2443) in paragraph at lines 145--149
Underfull \hbox (badness 2443) in paragraph at lines 164--168
[]\T1/LinuxLibertineT-TLF/m/n/7 (+20) CHERI-allocator/benchmarks/benchmarks/Str
essTestMalloc/glibc-bench.c at
[]
@@ -1537,14 +1534,14 @@ LaTeX2e <2024-11-01> patch level 2
L3 programming layer <2025-01-18>
***********
Package rerunfilecheck Info: File `paper.out' has not changed.
(rerunfilecheck) Checksum: E0A4BE03BD5F2BF273294833454E3065;4043.
(rerunfilecheck) Checksum: 21FD7693A5A3059545203AA7DB2EA238;4008.
)
Here is how much of TeX's memory you used:
24380 strings out of 473190
401897 string characters out of 5715801
979084 words of memory out of 5000000
46492 multiletter control sequences out of 15000+600000
779416 words of font info for 478 fonts, out of 8000000 for 9000
24399 strings out of 473190
402361 string characters out of 5715801
980070 words of memory out of 5000000
46493 multiletter control sequences out of 15000+600000
781348 words of font info for 490 fonts, out of 8000000 for 9000
1302 hyphenation exceptions out of 8191
90i,17n,131p,1002b,778s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/local/texlive/2025/texmf-dist/fonts/type1/public/inconsolata/Inconsolat
@@ -1559,10 +1556,10 @@ lic/libertine/LinLibertineTB.pfb></usr/local/texlive/2025/texmf-dist/fonts/type
/type1/public/newtx/NewTXMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1
/public/newtx/txmiaX.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public
/newtx/txsys.pfb>
Output written on paper.pdf (9 pages, 829590 bytes).
Output written on paper.pdf (9 pages, 830538 bytes).
PDF statistics:
388 PDF objects out of 1000 (max. 8388607)
323 compressed objects within 4 object streams
387 PDF objects out of 1000 (max. 8388607)
322 compressed objects within 4 object streams
67 named destinations out of 1000 (max. 500000)
123636 words of extra memory for PDF output out of 128383 (max. 10000000)
123628 words of extra memory for PDF output out of 128383 (max. 10000000)

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

Binary file not shown.

0
docs/EuroSys/Paper/paper.t Normal file
View File

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

@@ -252,8 +252,10 @@
The contribution is an alternative approach by exploiting capability-based addressing in the
CHERI architecture. This paper presents a new memory allocator called Fat Address Translations (FAT) which associates capabilities with memory pointers by integrating
block-based allocations within huge pages. The FAT allocator when ran independently and embedded inside Jemalloc reduces walking the TLB hierarchy by upto 90\%, which leads to decreasing runtimes
for memory read and write intensive applications.
block-based allocations within huge pages. When the FAT allocator is ran independently and embedded inside Jemalloc, it reduces by up to 99\% walking the TLB hierarchy. This leads to
decreasing runtimes for memory read and write intensive applications.
% The FAT allocator when ran independently and embedded inside Jemalloc reduces walking the TLB hierarchy by upto 90\%, which leads to decreasing runtimes
% for memory read and write intensive applications.
\end{abstract}
%%
@@ -338,7 +340,7 @@
In computing, achieving high performance is an ongoing challenge, especially as
applications handle increasingly memory intensive workloads. Performance referring to memory access rather than compute bound.
Memory management is a key factor in reducing the time it takes to access a memory region.
A Translation Lookaside Buffer (TLB) is a specialised cache in the memory management unit (MMU),
A Translation Lookaside Buffer (TLB) is a specialised cache in the memory management unit (MMU).
It reduces the time required to convert virtual addresses to physical addresses. When a program accesses
data in memory, the MMU first checks the TLB for a matching entry and avoids the slow process of
accessing the page tables situated in memory.
@@ -360,6 +362,11 @@ these bottlenecks.
% up memory-intensive applications, reducing latency in data access and enhancing throughput for
% workloads that rely heavily on large datasets.
% Ryad's comment:
% If the TLB's are linked to a core. Will they behave differently for multi-cores? and who manages this? I believe Cheri is not single-core.
% Did you cover this at some point in your work?
% Answer: The focus on this paper is on single core execution.
Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
~\cite{woodruff_cheri_2014} which are pointers that are replaced with capabilities with 128-bit or 256-bit
encoding scheme which consists of both the address and metadata. The metadata includes bounds, permissions and validity of the pointer
@@ -388,8 +395,8 @@ memory allocations by emulating block allocations on physically contiguous memor
memory allocation using a block-based strategy with capability-based addressing (Section ~\ref{sec:JemallocFATAllocator}).
\end{itemize}
Through evaluating micro and macro benchmarks, FAT though the use of CHERI's capabilities and huge pages demonstrates the allocator's ability
to reduce TLB misses by up to 90\% which yields to improvements of wall clock runtimes by upto 6\% for memory-intensive
Through evaluating micro and macro benchmarks the FAT allocator though the use of CHERI's capabilities and huge pages demonstrates the allocator's ability
to reduce TLB walks by up to 99\% which yields to improvements of wall clock runtimes by upto 6\% for memory-intensive
applications. While its impact on larger and computation-heavy workloads is less pronounced.
The proposed allocator shows strong potential for advancing memory management in scenarios requiring
high memory throughput by reducing the address translation overhead.
@@ -467,6 +474,11 @@ concurrently with address computation. Simulation results show that FlexPointer
in a range of memory-intensive workloads. When compared with a traditional 4KB-page system, FlexPointer delivers an average performance improvement
of 14\%, with peak gains of up to 2.8×, and introduces no performance regressions in less demanding scenarios.
% Ryad comment:
% Is this from reference 12?
% Does the whole section refer to reference 12?
% The whole section is reference 12
\subsection{CHERI}
\label{sec:orgbf2eaac}
@@ -563,7 +575,7 @@ in this implementation is the use of range addresses with CHERI CC~\cite{woodruf
% information encoded in the pointer. The bounds encoded in the pointer is reused for tracking memory blocks within a huge page. As shown this in
% turn reduces the TLB pressure.
Figure \ref{fig:HighOverviewArchitecture} illustrates a high-level overview of the FAT allocator. The rectangular box represents
Figure \ref{fig:HighOverviewArchitecture} illustrates a high-level overview of the FAT allocator. The dotted rectangular box represents
addresses in memory, and the box from v1 to v100 represents a physically contiguous region of memory. This physically contiguous
region is typically allocated using huge pages. When malloc is called, a capability pointer is returned with metadata related to
the bounds information encoded within the pointer. The bounds encoded in the pointer are reused for tracking memory blocks within a
@@ -605,7 +617,7 @@ which is called when there is a L1 TLB miss. FlexPointer builds up on the work o
and 64th bit which is the value to check the range table on parallel to the L1 TLB lookup.
The FAT allocator builds up on the concept of range from RMM and FlexPointer. Instead of using a
hardware range table using CHERI, range information can be encoded within a capability pointer.
hardware range table using CHERI range information can be encoded within a capability pointer.
A memory range in FAT has two points to track memory in physically contiguous space which
is the top and bottom. These two points are two virtual addresses and the range consists of
addresses that lie within this and refers to addresses allocated by invoking \textit{malloc}.
@@ -820,7 +832,7 @@ applications and kernel-level operations.
\section{Embedding FAT allocator inside Jemalloc}
\label{sec:JemallocFATAllocator}
This section describes about the FAT allocator implementation (Section \ref{sec:MemoryAllocator}) embedded inside Jemalloc. The objective here is to describe the changes needed
This section describes the FAT allocator implementation (Section \ref{sec:MemoryAllocator}) embedded inside Jemalloc. The objective here is to describe the changes needed
for a block based allocator to use physically contigous memory with a block based strategy with the help of capability based addresses.
In the case of Jemalloc the only changes required was to replace the mmap with the \textit{malloc} function (Algorithm \ref{alg:malloc}) and
for munmap the \textit{free} function (Algorithm \ref{alg:free}).
@@ -880,7 +892,7 @@ for munmap the \textit{free} function (Algorithm \ref{alg:free}).
The os\_pages\_map function (Algorithm~\ref{alg:JemallocMalloc}) simulates jemalloc's low-level page
mapping routine. It first checks if a specific address is
requested in case relevant to CheriABI where such behavior
requested in case relevant to CheriABI~\cite{CheriABI} where such behavior
is disallowed and returns NULL. It then allocates memory using the custom MALLOC(size) (Algorithm~\ref{alg:malloc}) function and validates
whether the returned pointer matches the requested address
if one was provided. If there's a mismatch, it unmaps calling FREE() (Algorithm~\ref{alg:free}) the
@@ -909,7 +921,7 @@ predefined structures, jemalloc minimizes fragmentation~\cite{evans_scalable_nod
\end{algorithmic}
\end{algorithm}
\subsection{Mumap replaced with FREE}
\subsection{Munmap replaced with FREE}
The os\_pages\_unmap (Algorithm~\ref{alg:JemallocFree}) represents a customized abstraction of jemallocs
memory unmapping routine, designed to integrate with the previously defined simplified
@@ -929,7 +941,7 @@ FREE(addr) (Algorithm~\ref{alg:free}) operation.
The following changes done to free is embedded inside jemalloc's deallocation mechanism,
where metadata associated with each allocation
(such as size and location) is used to efficiently return memory to the appropriate
arena or pool. jemalloc maintains
arena or pool. Jemalloc maintains
separate metadata structures to track allocations, allowing for quick deallocation and
reuse of memory blocks
without significant overhead~\cite{evans_scalable_nodate}.
@@ -942,7 +954,7 @@ without significant overhead~\cite{evans_scalable_nodate}.
\label{sec:Evaluation}
Benchmarks of the FAT memory allocator and the FAT allocator embedded within Jemalloc against the standard Jemalloc~\cite{jemalloc} allocator was conducted.
Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}. The objective was to evaluate
the reduction of TLB walks ,misses and its impact on the wall clock runtime.
the reduction of TLB walks and misses and its impact on the wall clock runtime.
To comprehensively analyse the proposed allocator, the benchmarks~\cite{Benchmark} were categorised into
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
@@ -1098,7 +1110,7 @@ This extension is described by Holt and Singh ~\cite{holt1995}.
\end{itemize}
\subsection{Results}
\subsection{Results and discussion}
\label{sec:Results}
% \begin{figure}[b]
@@ -1213,46 +1225,65 @@ of its capability to handle memory more efficiently by leveraging huge pages.
% FAT allocator embedded inside Jemalloc. These results suggest that FAT allocator embedded inside Jemalloc may arrange memory
% in a manner that enhances spatial locality at the page level, particularly for workloads like Memaccess and Glibc.
\item L1 DTLB reads: L1 DTLB reads are critical for achieving fast memory access; therefore, a
\item L1 TLB reads: L1 TLB reads are critical for achieving fast memory access; therefore, a
reduction in events that could signify misses or lead to further lookups is generally beneficial.
In the Kmeans benchmark, the FAT allocator demonstrated 23\% fewer L1 DTLB reads than the baseline allocator.
However, when the FAT allocator was embedded within Jemalloc, the L1 DTLB reads were the same as the baseline.
For the memaccess benchmark, the embedded FAT allocator resulted in 72\% fewer L1 DTLB reads compared to the baseline
allocator. A similar pattern was observed with Glibc, showing 62\% fewer L1 DTLB reads. In the Richards benchmark,
there was no discernible difference for either allocator. For the Barnes benchmark, the FAT allocator exhibited 5\%
fewer L1 DTLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.
In the Kmeans benchmark, the FAT allocator demonstrated 13\% fewer L1 TLB reads than the baseline allocator.
However, when the FAT allocator was embedded within Jemalloc, the L1 TLB reads were the same as the baseline.
For the memaccess benchmark, the embedded FAT allocator resulted in 68\% fewer L1 TLB reads compared to the baseline
allocator. A similar pattern was observed with Glibc, showing 59\% fewer L1 TLB reads. In the Richards benchmark,
there was no difference for either allocator. For the Barnes benchmark, the FAT allocator exhibited 5\%
fewer L1 TLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.
\item L2 DTLB reads: L2 Data TLB reads (or lookups) serve as a secondary cache for address translations, and, similar to L1 TLB, lower values are
indicative of better performance. FAT allocator consistently performed at the baseline (100\%) for this metric across all benchmarks except Barnes.
FAT allocator embedded inside Jemalloc also showed no significant change for Kmeans, Memaccess, and Richards. However, for the Glibc benchmark,
it achieved a significant reduction of 60\% in L2D TLB reads. This mirrors its L1D TLB improvement for Glibc and suggests that its
\item L2 TLB reads: L2 Data TLB reads (or lookups) serve as a secondary cache for address translations.
FAT allocator consistently performed at 98\% lesser L2 TLB reads for this metric across all benchmarks except Barnes
which was 4\% lesser. FAT allocator embedded inside Jemalloc also showed significant change for Kmeans, Memaccess, and Richards. However, for the Glibc benchmark
it achieved a reduction of 60\% in L2 TLB reads. This mirrors its L1D TLB improvement for Glibc and suggests that its
strategy for page locality extends effectively to deeper levels of the TLB hierarchy for this particular benchmark, which is notable given
Glibc's high frequency of malloc calls that stress memory management. A minor reduction of 3\% was also observed for the Barnes
Glibc's high frequency of malloc calls that stress memory management. A minor reduction of 5 \% was also observed for the Barnes
benchmark with FAT allocator embedded inside Jemalloc.
\item DTLB walks: which occur when a virtual-to-physical
address translation is not found in the DTLB and a page table traversal is necessary, represent a performance
cost. thus, fewer walks are preferable. In the observed tests neither FAT allocator nor FAT allocator embedded inside Jemalloc
demonstrated any significant deviation from the baseline performance (100\%) for this metric.
demonstrated significant deviation from the baseline performance of 99\% lesser walks.
This consistent behavior was noted across all benchmarks evaluated: Kmeans, Memaccess, Glibc, Richards, and Barnes.
This outcome suggests that the memory allocation strategies employed by these allocators do not substantially alter the frequency
of DTLB misses that necessitate page table walks within these specific workloads. Even for the Memaccess benchmark,
which is designed with random list traversals that can stress TLB pressure, the impact on dTLB walks was negligible according to the provided graphs.
This outcome suggests that most translations were done at the L1 DTLB level.
\item L1 DTLB refills: L1 Data TLB refills are a direct consequence of L1D TLB misses, with fewer refills indicating better performance.
Interestingly, despite the variations observed in L1D TLB reads for FAT allocator embedded inside Jemalloc, the L1D TLB refills metric
remained at the baseline (100\%) for both FAT allocator and FAT allocator embedded inside Jemalloc. This consistent performance at baseline
was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes. This outcome presents a point of potential inconsistency;
if L1D TLB reads (interpreted as events related to misses or lookups that could lead to misses) are reduced, a corresponding decrease in actual
refills would typically be expected.
% the memory allocation strategies employed by these allocators do substantially alter the frequency
% of DTLB misses that necessitate page table walks within these specific workloads. Even for the Memaccess benchmark,
% which is designed with random list traversals that can stress TLB pressure, the impact on dTLB walks was negligible according to the provided graphs.
\item L1 TLB refills: L1 Data TLB refills are a direct consequence of L1 TLB misses; therefore, fewer refills
indicate better performance. Interestingly, despite the variations observed in L1 TLB reads for the FAT allocator
embedded within Jemalloc, the L1 TLB refills metric showed a significant reduction of 99\% for both the standalone
FAT allocator and the FAT allocator embedded within Jemalloc. This consistent and substantial improvement over the baseline was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes.
% L1 Data TLB refills are a direct consequence of L1D TLB misses, with fewer refills indicating better performance.
% Interestingly, despite the variations observed in L1D TLB reads for FAT allocator embedded inside Jemalloc, the L1D TLB refills metric
% resulted at a significant reduction of 99\% lesser for both FAT allocator and FAT allocator embedded inside Jemalloc. This consistent performance at baseline
% was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes.
% The absence of change in refills might suggest that the "reads" metric captures a wider range of TLB interaction
% events than solely those leading to refills, or perhaps the absolute number of critical misses resulting in refills was minimal to begin with and thus
% not significantly affected by the allocators in these tests.
% \item Last-level cache: Last-Level Cache read misses are crucial performance indicators, as they often result in slow data fetches
% from main memory therefore fewer misses are highly desirable. The performance on this metric varied significantly between the
% allocators and across benchmarks.
\item Last-level cache: Cache read misses in the Last-Level Cache (LLC) are critical performance indicators, as they typically lead to
slower data retrievals from main memory. Consequently, a lower number of misses is highly desirable. The performance on this
metric varied considerably across both allocators and benchmarks. The FAT allocator exhibited the highest variance in the
kmeans benchmark, achieving 57\% fewer cache misses compared to the baseline allocator. In contrast, it recorded 18\% more
misses in memaccess, 65\% fewer in glibc, 31\% more in Richards, and 18\% more in barnes.
When the FAT allocator was embedded within jemalloc, the results shifted notably: kmeans experienced 19\% more misses
relative to the baseline, memaccess saw a substantial 77\% reduction, while glibc incurred a dramatic 370\% increase particularly
significant given its malloc intensive nature. There was no change in LLC misses for Richards, whereas barnes suffered from 68\%
more misses.
% Last-Level Cache read misses are crucial performance indicators, as they often result in slow data fetches
% from main memory therefore fewer misses are highly desirable. The performance on this metric varied significantly between the
% allocators and across benchmarks. FAT allocator had a highest variance for kmeans with 57\% lesser cache misses than than the
% baseline allocator, memaccess with 18\% more, Glibc with 65\% less, Richards with 31\% more and barnes with 18\% more as well.
% In the case of FAT allocator embedded inside jemalloc kmeans stands with 19\% more misses than the baseline allocator, memaccess with 77\%
% lesser misses, Glibc with 370\% more misses which is significant especially being malloc heavy benchmark, Richards has no difference in
% LL cache misses and barnes has a 68\% more cache misses.
% FAT allocator was near baseline for Kmeans but caused an 18\% increase in misses for Memaccess (designed to stress cache ),
% a 30\% increase for Richards (many dynamic allocations and pointer manipulations ), and an 18\% increase for Barnes (uses pointer-based octrees ). However,
% FAT allocator achieved a significant 60\% reduction in misses for the Glibc benchmark, which involves active memory use post-allocation.
@@ -1261,7 +1292,20 @@ of its capability to handle memory more efficiently by leveraging huge pages.
% This high variability indicates that memory placement strategies of the allocators interact diversely with the specific access patterns of each benchmark,
% such as the difference between the large data arrays in K-Means versus the linked structures common in Memaccess or Richards.
% \item Wall clock: Wallclock time provides the ultimate measure of overall execution performance, where lower values (deviations below 100\%) indicate improvement.
\item Wall clock: Wallclock time serves as the definitive metric for evaluating overall execution performance.
When using the FAT allocator, glibc demonstrated the most significant improvement, with a 51\% reduction in wallclock
runtime compared to the baseline allocator. This was followed by memaccess with a 34\% decrease, barnes with a 4\% reduction,
and kmeans with a modest 1.8\% improvement. Conversely, Richards exhibited a slight increase of 1\% in runtime.
When the FAT allocator was integrated into jemalloc, the performance impact varied. Glibc experienced a 16.2\% increase
in wallclock time, while barnes showed a 7\% rise. Both Richards and kmeans maintained the same runtime as the baseline
allocator, whereas memaccess recorded a 4\% reduction.
% Wallclock time provides the ultimate measure of overall execution performance, In terms of the FAT allocator GLibc
% had a biggest difference of 51\% lesser wall clock run time than the baseline allocator, following this memaccess with a 34\% reduction
% , 3rd being Barnes being 4\% lesser, 4th being Kmeans with 1.8\% less and Richards having 1\% more. In terms of Jemalloc embedded inside
% the FAT allocator Glibc having a increased wall clock run time of 16.2\%, followed by Barnes with a 7\% increase, Richards and Kmeans
% with the same wall clock run time as the baseline allocator. Memaccess showed a decrease in the wall clock runtime by 4\%.
% where lower values (deviations below 100\%) indicate improvement.
% FAT allocator resulted in a 1\% speedup for Kmeans and a more significant 5\% speedup for Barnes. This improvement for Barnes was observed despite an increase
% in its LL cache misses, suggesting other factors such as reduced allocator overhead or better CPU pipeline utilization might have contributed.
% For Memaccess and Glibc, FAT allocator performed at the baseline. Notably, the substantial LL cache miss reduction seen with FAT allocator on Glibc did not
@@ -1292,7 +1336,7 @@ exhibit minimal differences in wall clock runtimes when using the FAT allocator.
This outcome is expected, as macro benchmarks typically involve a broader range of operations
beyond memory allocation. Additionally,
the benefits of huge pages may be less pronounced for these workloads, as they are often
bottlenecked by factors such as computation or I/O rather than memory translation overhead.z
bottlenecked by factors such as computation or I/O rather than memory translation overhead.
% \begin{figure}[htbp]
% \centering
@@ -1327,24 +1371,24 @@ bottlenecked by factors such as computation or I/O rather than memory translatio
% 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}
% \subsection{Analysis}
% \label{sec:Analysis}
The FAT memory allocator and the modified Jemalloc demonstrates significant potential for enhancing
memory management in systems that benefit from huge page optimisations. Its design
effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
and TLB refills compared to the system allocator (i.e default Jemalloc). These improvements lead to noticeable performance
gains especially in micro benchmarks, where the allocator reduces wall clock runtimes
by an average of 50\%.
% The FAT memory allocator and the modified Jemalloc demonstrates significant potential for enhancing
% memory management in systems that benefit from huge page optimisations. Its design
% effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
% and TLB refills compared to the system allocator (i.e default Jemalloc). These improvements lead to noticeable performance
% gains especially in micro benchmarks, where the allocator reduces wall clock runtimes
% by an average of 50\%.
% The allocator integrates seamlessly into memory read intensive workloads, as evidenced by its
% consistent performance across varying cluster sizes in the K-means benchmark with only
% minor anomalies observed under specific conditions. These outliers provide valuable
% insights into the allocators interaction with system-level caching and memory translation mechanisms.
While the allocator excels in scenarios emphasising on high-memory throughput. Its impact on
macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
applications with frequent and intensive memory operations rather than are compute-bound workloads.
% While the allocator excels in scenarios emphasising on high-memory throughput. Its impact on
% macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
% applications with frequent and intensive memory operations rather than are compute-bound workloads.
% \section{Future work}
% The current experimental setup on the ARM Morello board is constrained by the requirement that all memory reads must

18
docs/EuroSys/Paper/paperReferences.bib
View File

@@ -623,4 +623,22 @@ series = {WCAE '03}
file = {Evans - A Scalable Concurrent malloc(3) Implementation for.pdf:/Users/akilan/Zotero/storage/4ZE7JS5V/Evans - A Scalable Concurrent malloc(3) Implementation for.pdf:application/pdf},
}
@inproceedings{CheriABI,
author = {Davis, Brooks and Watson, Robert N. M. and Richardson, Alexander and Neumann, Peter G. and Moore, Simon W. and Baldwin, John and Chisnall, David and Clarke, Jessica and Filardo, Nathaniel Wesley and Gudka, Khilan and Joannou, Alexandre and Laurie, Ben and Markettos, A. Theodore and Maste, J. Edward and Mazzinghi, Alfredo and Napierala, Edward Tomasz and Norton, Robert M. and Roe, Michael and Sewell, Peter and Son, Stacey and Woodruff, Jonathan},
title = {CheriABI: Enforcing Valid Pointer Provenance and Minimizing Pointer Privilege in the POSIX C Run-time Environment},
year = {2019},
isbn = {9781450362405},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/3297858.3304042},
doi = {10.1145/3297858.3304042},
abstract = {The CHERI architecture allows pointers to be implemented as capabilities (rather than integer virtual addresses) in a manner that is compatible with, and strengthens, the semantics of the C language. In addition to the spatial protections offered by conventional fat pointers, CHERI capabilities offer strong integrity, enforced provenance validity, and access monotonicity. The stronger guarantees of these architectural capabilities must be reconciled with the real-world behavior of operating systems, run-time environments, and applications. When the process model, user-kernel interactions, dynamic linking, and memory management are all considered, we observe that simple derivation of architectural capabilities is insufficient to describe appropriate access to memory. We bridge this conceptual gap with a notional abstract capability that describes the accesses that should be allowed at a given point in execution, whether in the kernel or userspace. To investigate this notion at scale, we describe the first adaptation of a full C-language operating system (FreeBSD) with an enterprise database (PostgreSQL) for complete spatial and referential memory safety. We show that awareness of abstract capabilities, coupled with CHERI architectural capabilities, can provide more complete protection, strong compatibility, and acceptable performance overhead compared with the pre-CHERI baseline and software-only approaches. Our observations also have potentially significant implications for other mitigation techniques.},
booktitle = {Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems},
pages = {379–393},
numpages = {15},
keywords = {cheri, hardware, operating systems, security},
location = {Providence, RI, USA},
series = {ASPLOS '19}
}

BIN
docs/FutureTasks/.DS_Store vendored
View File

Binary file not shown.

128
docs/FutureTasks/Plan/FuturePlan.bib Normal file
View File

@@ -0,0 +1,128 @@
@article{woodruff_cheri_2019,
title = {{CHERI} {Concentrate}: {Practical} {Compressed} {Capabilities}},
volume = {68},
copyright = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/IEEE.html},
issn = {0018-9340, 1557-9956, 2326-3814},
shorttitle = {{CHERI} {Concentrate}},
url = {https://ieeexplore.ieee.org/document/8703061/},
doi = {10.1109/TC.2019.2914037},
abstract = {We present CHERI Concentrate, a new fat-pointer compression scheme applied to CHERI, the most developed capability-pointer system at present. Capability fat pointers are a primary candidate to enforce fine-grained and non-bypassable security properties in future computer systems, although increased pointer size can severely affect performance. Thus, several proposals for capability compression have been suggested elsewhere that do not support legacy instruction sets, ignore features critical to the existing software base, and also introduce design inefficiencies to RISC-style processor pipelines. CHERI Concentrate improves on the state-of-the-art region-encoding efficiency, solves important pipeline problems, and eases semantic restrictions of compressed encoding, allowing it to protect a full legacy software stack. We present the first quantitative analysis of compiled capability code, which we use to guide the design of the encoding format. We analyze and extend logic from the open-source CHERI prototype processor design on FPGA to demonstrate encoding efficiency, minimize delay of pointer arithmetic, and eliminate additional load-to-use delay. To verify correctness of our proposed high-performance logic, we present a HOL4 machine-checked proof of the decode and pointer-modify operations. Finally, we measure a 50\% to 75\% reduction in L2 misses for many compiled C-language benchmarks running under a commodity operating system using compressed 128-bit and 64-bit formats, demonstrating both compatibility with and increased performance over the uncompressed, 256-bit format.},
language = {en},
number = {10},
urldate = {2024-05-27},
journal = {IEEE Transactions on Computers},
author = {Woodruff, Jonathan and Joannou, Alexandre and Xia, Hongyan and Fox, Anthony and Norton, Robert M. and Chisnall, David and Davis, Brooks and Gudka, Khilan and Filardo, Nathaniel W. and Markettos, A. Theodore and Roe, Michael and Neumann, Peter G. and Watson, Robert N. M. and Moore, Simon W.},
month = oct,
year = {2019},
pages = {1455--1469},
file = {Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:/Users/akilan/Zotero/storage/3SZUIWQ5/Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:application/pdf},
}
@misc{noauthor_jemalloc_nodate,
title = {{JEMALLOC}},
url = {https://jemalloc.net/jemalloc.3.html},
urldate = {2025-01-15},
file = {JEMALLOC:/Users/akilan/Zotero/storage/QDEIEJ9N/jemalloc.3.html:text/html},
}
@misc{noauthor_arm_nodate,
title = {Arm {Architecture} {Reference} {Manual} for {A}-profile architecture},
url = {https://developer.arm.com/documentation/ddi0487/latest},
urldate = {2025-01-15},
file = {Arm Architecture Reference Manual for A-profile architecture:/Users/akilan/Zotero/storage/BVZSP7HA/latest.html:text/html},
}
@misc{noauthor_department_nodate,
title = {Department of {Computer} {Science} and {Technology} – {CHERI}: {The} {Arm} {Morello} {Board}},
url = {https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html},
urldate = {2025-01-16},
file = {Department of Computer Science and Technology – CHERI\: The Arm Morello Board:/Users/akilan/Zotero/storage/GCMNX8LY/cheri-morello.html:text/html},
}
@article{navarro_practical_nodate,
title = {Practical, transparent operating system support for superpages},
abstract = {Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer (TLB) to map a large physical memory region into a virtual address space. This dramatically increases TLB coverage, reduces TLB misses, and promises performance improvements for many applications. However, supporting superpages poses several challenges to the operating system, in terms of superpage allocation and promotion tradeoffs, fragmentation control, etc. We analyze these issues, and propose the design of an effective superpage management system. We implement it in FreeBSD on the Alpha CPU, and evaluate it on real workloads and benchmarks. We obtain substantial performance benefits, often exceeding 30\%; these benefits are sustained even under stressful workload scenarios.},
language = {en},
author = {Navarro, Juan},
file = {Navarro - Practical, transparent operating system support fo.pdf:/Users/akilan/Zotero/storage/R9MSCWQX/Navarro - Practical, transparent operating system support fo.pdf:application/pdf},
}
@misc{noauthor_ctsrd-cheritoooba_nodate,
title = {{CTSRD}-{CHERI}/{Toooba}: {RISC}-{V} {Core}; superscalar, out-of-order, multi-core capable; based on {RISCY}-{OOO} from {MIT}},
url = {https://github.com/CTSRD-CHERI/Toooba},
urldate = {2025-02-25},
file = {CTSRD-CHERI/Toooba\: RISC-V Core\; superscalar, out-of-order, multi-core capable\; based on RISCY-OOO from MIT:/Users/akilan/Zotero/storage/BQPSL2D6/Toooba.html:text/html},
}
@article{witaszczyk_pure-capability_nodate,
title = {Pure-capability third-party software for {Arm} {Morello} and {CHERI}-{RISC}-{V} {CheriBSD}},
language = {en},
author = {Witaszczyk, Konrad},
file = {Witaszczyk - Pure-capability third-party software for Arm Morel.pdf:/Users/akilan/Zotero/storage/549XSPL6/Witaszczyk - Pure-capability third-party software for Arm Morel.pdf:application/pdf},
}
@article{bluespec,
author = {Nikhil, Rishiyur S. and Arvind},
title = {What is Bluespec?},
year = {2008},
issue_date = {December 2008},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {38},
number = {23},
issn = {0163-5743},
url = {https://doi.org/10.1145/1862867.1862868},
doi = {10.1145/1862867.1862868},
abstract = {Bluespec refers to a language and associated tools which are being used for all aspects of hardware system design . specification, synthesis, modeling, and verification. The language, BSV (Bluespec SystemVerilog), is based on a new model of computation for hardware, where all behavior is described as a set of rewrite rules, or Guarded Atomic Actions. Unlike the process/thread model of Verilog, VHDL and SystemC, or the sequential model of C/C++, all behavior of a BSV program can be understood in terms of atomic rule firings. This computational model has a long pedigree in formal specification and verification systems (e.g., Dijkstra's Guarded Commands, UNITY, TLA+, and EventB), and BSV makes it available for hardware design.},
journal = {SIGDA Newsl.},
month = dec,
pages = {1},
numpages = {1}
}
@incollection{bsv,
address = {Cham},
title = {Bluespec {SystemVerilog}},
isbn = {978-3-319-26408-0},
url = {https://doi.org/10.1007/978-3-319-26408-0_9},
abstract = {Bluespec SystemVerilog (BSV) is a rule-based language, where hardware is described as object-oriented modules. Other high-level synthesis approaches try to hide the complexity of hardware (clock cycles, data movement, concurrency, etc.) under the appearance of a sequential and centralized execution. Instead, BSV exposes it to the user as an intuitive high-level metaphor. This language is a good candidate for expert hardware designers with a background on Register-Transfer Level (RTL) languages, such as Verilog or VHDL, for designers that have to develop critical hardware components, or for keeping a very tight control over the performance and the resources used. This chapter introduces the basic concepts of Bluespec SystemVerilog.},
booktitle = {{FPGAs} for {Software} {Programmers}},
publisher = {Springer International Publishing},
author = {Arcas-Abella, Oriol and Sonmez, Nehir},
editor = {Koch, Dirk and Hannig, Frank and Ziener, Daniel},
year = {2016},
doi = {10.1007/978-3-319-26408-0_9},
pages = {165--172},
}
@inproceedings{Coz,
author = {Curtsinger, Charlie and Berger, Emery D.},
title = {Coz: finding code that counts with causal profiling},
year = {2015},
isbn = {9781450338349},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/2815400.2815409},
doi = {10.1145/2815400.2815409},
abstract = {Improving performance is a central concern for software developers. To locate optimization opportunities, developers rely on software profilers. However, these profilers only report where programs spent their time: optimizing that code may have no impact on performance. Past profilers thus both waste developer time and make it difficult for them to uncover significant optimization opportunities.This paper introduces causal profiling. Unlike past profiling approaches, causal profiling indicates exactly where programmers should focus their optimization efforts, and quantifies their potential impact. Causal profiling works by running performance experiments during program execution. Each experiment calculates the impact of any potential optimization by virtually speeding up code: inserting pauses that slow down all other code running concurrently. The key insight is that this slowdown has the same relative effect as running that line faster, thus "virtually" speeding it up.We present Coz, a causal profiler, which we evaluate on a range of highly-tuned applications: Memcached, SQLite, and the PARSEC benchmark suite. Coz identifies previously unknown optimization opportunities that are both significant and targeted. Guided by Coz, we improve the performance of Memcached by 9\%, SQLite by 25\%, and accelerate six PARSEC applications by as much as 68\%; in most cases, these optimizations involve modifying under 10 lines of code.},
booktitle = {Proceedings of the 25th Symposium on Operating Systems Principles},
pages = {184–197},
numpages = {14},
location = {Monterey, California},
series = {SOSP '15}
}
@article{Toooba, title={Efficient spatial and temporal safety for microcontrollers and application-class processors}, url={https://www.repository.cam.ac.uk/handle/1810/353468}, DOI={10.17863/CAM.99588}, school={Apollo - University of Cambridge Repository}, author={Rugg, Peter}, year={2022}, keywords={CHERI, Hardware design, Memory safety, RISC-V} }
@inproceedings {FleetAllocator,
author = {A.H. Hunter and Chris Kennelly and Paul Turner and Darryl Gove and Tipp Moseley and Parthasarathy Ranganathan},
title = {Beyond malloc efficiency to fleet efficiency: a hugepage-aware memory allocator},
booktitle = {15th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 21)},
year = {2021},
isbn = {978-1-939133-22-9},
pages = {257--273},
url = {https://www.usenix.org/conference/osdi21/presentation/hunter},
publisher = {{USENIX} Association},
month = jul
}

BIN
docs/FutureTasks/Plan/memory_allocator.drawio.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 415 KiB

73
docs/FutureTasks/Plan/plan-1.bbl Normal file
View File

@@ -0,0 +1,73 @@
% Generated by IEEEtran.bst, version: 1.14 (2015/08/26)
\begin{thebibliography}{1}
\providecommand{\url}[1]{#1}
\csname url@samestyle\endcsname
\providecommand{\newblock}{\relax}
\providecommand{\bibinfo}[2]{#2}
\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
\providecommand{\BIBentryALTinterwordstretchfactor}{4}
\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
\fontdimen4\font\relax}
\providecommand{\BIBforeignlanguage}[2]{{%
\expandafter\ifx\csname l@#1\endcsname\relax
\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%
\typeout{** loaded for the language `#1'. Using the pattern for}%
\typeout{** the default language instead.}%
\else
\language=\csname l@#1\endcsname
\fi
#2}}
\providecommand{\BIBdecl}{\relax}
\BIBdecl
\bibitem{coz}
\BIBentryALTinterwordspacing
C.~Curtsinger and E.~D. Berger, ``Coz: finding code that counts with causal
profiling,'' in \emph{Proceedings of the 25th Symposium on Operating Systems
Principles}, ser. SOSP '15.\hskip 1em plus 0.5em minus 0.4em\relax New York,
NY, USA: Association for Computing Machinery, 2015, p. 184–197. [Online].
Available: \url{https://doi.org/10.1145/2815400.2815409}
\BIBentrySTDinterwordspacing
\bibitem{Toooba}
\BIBentryALTinterwordspacing
P.~Rugg, ``Efficient spatial and temporal safety for microcontrollers and
application-class processors,'' 2022. [Online]. Available:
\url{https://www.repository.cam.ac.uk/handle/1810/353468}
\BIBentrySTDinterwordspacing
\bibitem{bluespec}
\BIBentryALTinterwordspacing
R.~S. Nikhil and Arvind, ``What is bluespec?'' \emph{SIGDA Newsl.}, vol.~38,
no.~23, p.~1, Dec. 2008. [Online]. Available:
\url{https://doi.org/10.1145/1862867.1862868}
\BIBentrySTDinterwordspacing
\bibitem{bsv}
\BIBentryALTinterwordspacing
O.~Arcas-Abella and N.~Sonmez, ``Bluespec {SystemVerilog},'' in \emph{{FPGAs}
for {Software} {Programmers}}, D.~Koch, F.~Hannig, and D.~Ziener, Eds.\hskip
1em plus 0.5em minus 0.4em\relax Cham: Springer International Publishing,
2016, pp. 165--172. [Online]. Available:
\url{https://doi.org/10.1007/978-3-319-26408-0_9}
\BIBentrySTDinterwordspacing
\bibitem{noauthor_arm_nodate}
\BIBentryALTinterwordspacing
``Arm {Architecture} {Reference} {Manual} for {A}-profile architecture.''
[Online]. Available:
\url{https://developer.arm.com/documentation/ddi0487/latest}
\BIBentrySTDinterwordspacing
\bibitem{FleetAllocator}
\BIBentryALTinterwordspacing
A.~Hunter, C.~Kennelly, P.~Turner, D.~Gove, T.~Moseley, and P.~Ranganathan,
``Beyond malloc efficiency to fleet efficiency: a hugepage-aware memory
allocator,'' in \emph{15th {USENIX} Symposium on Operating Systems Design and
Implementation ({OSDI} 21)}.\hskip 1em plus 0.5em minus 0.4em\relax {USENIX}
Association, Jul. 2021, pp. 257--273. [Online]. Available:
\url{https://www.usenix.org/conference/osdi21/presentation/hunter}
\BIBentrySTDinterwordspacing
\end{thebibliography}

260
docs/FutureTasks/Plan/plan-1.org
View File

@@ -2,12 +2,12 @@
This document outlines the proposed PhD research plan for the forthcoming academic year, building upon the outcomes and insights gained during the preceding year.
** Current experiments:
1. FAT allocator with huge pages.
2. FAT allocator to bypass TLB.
3. Allocator evaluation based on stripping instruction calls for larger allocators.
- (Experiment 1)FAT allocator with huge pages (EuroSys26 paper draft)
- (Experiment 2)FAT allocator to bypass TLB. (Proposal of ongoing expirement)
- (Experiment 3)Allocator evaluation based on stripping instruction calls from larger allocators. (Appendix)
** Experiment cancelled:
1. Uni-Kernel Development: Work scaled down to fit within the allocated PhD timeframe and introduced an extension of the FAT allocator as the third experiment.
1. Uni-Kernel Development (Reason): Work scaled down to fit within the allocated within PhD timeframe and instead introduced an extension of the FAT allocator as the third experiment.
** Link to the Previous PhD Plan
- https://github.com/Akilan1999/phd-thesis/releases/download/Year2/thesis.pdf
@@ -16,7 +16,7 @@ This document outlines the proposed PhD research plan for the forthcoming academ
*** Phase 1: FAT-Pointer Mechanism (July–September 2024)
**** 1st to 15th July 2024
- Investigated causes of L1 TLB misses associated with contiguous memory allocation.
- Executed performance benchmarking using COZ on selected C programs.
- Executed performance benchmarking using COZ\cite{coz} on selected C programs.
- Ported the kernel module to support SnMalloc, the default allocator in CheriBSD.
**** 15th to 30th July 2024
@@ -24,7 +24,7 @@ This document outlines the proposed PhD research plan for the forthcoming academ
- Performed comparative analysis with both baseline and modified SnMalloc implementations.
**** August 2024
- Initiated drafting of a paper for submission to EuroSys, focusing on the FAT-Pointer memory allocator.
- Initiated drafting of a paper for submission to EuroSys, focusing on the FAT-Pointer memory allocator (Current: On review stage).
**** September 2024
- Compiled and structured thesis chapter related to the FAT-Pointer architecture.
@@ -32,12 +32,12 @@ This document outlines the proposed PhD research plan for the forthcoming academ
*** Phase 2: RISC-V Integration (October 2024 – May 2025)
**** October to December 2024
- Modified the Bluespec implementation to enable TLB bypass in the memory access pipeline.
- Configured the experimental platform and evaluation toolchain.
- Modified the Bluespec implementation to enable TLB bypass in the memory access pipeline (Current: On progress).
- Configured the experimental platform and evaluation toolchain (Current: On progress).
**** January to February 2025
- Undertook experimental evaluation of the FAT-Pointer system on RISC-V (Toooba).
- Commenced drafting of a technical paper for ISMM based on RISC-V integration results.
- Undertook experimental evaluation of the FAT-Pointer system on RISC-V (Toooba) (Current: Todo).
- Commenced drafting of a technical paper for ISMM based on RISC-V integration results (Current: Todo).
**** March to May 2025
- Addressed outstanding tasks and technical backlog.
@@ -45,62 +45,236 @@ This document outlines the proposed PhD research plan for the forthcoming academ
*** Phase 3: Uni-Kernel Deployment (May 2025 – September 2026)
**** May to December 2025
- Ported the memory allocator to a CHERI-enabled Uni-Kernel environment.
- Designed and implemented a unified memory allocator to support both kernel and user-level allocations.
- Initiated drafting of a manuscript targeted at OSDI.
- Ported the memory allocator to a CHERI-enabled Uni-Kernel environment (Current: Cancelled)
- Designed and implemented a unified memory allocator to support both kernel and user-level allocations (Current: Cancelled)
- Initiated drafting of a manuscript targeted at OSDI (Current: Cancelled)
**** January to September 2026
- Finalised documentation and submission of the PhD thesis.
- Submitted third research paper based on extended evaluation.
- Finalised documentation and submission of the PhD thesis (Current: New plan to still keep these dates unchanged)
- Submitted third research paper based on extended evaluation (Current: Replaced with "Allocator evaluation based on stripping instruction calls from larger allocators")
** Current Research Plan
This section outlines a comprehensive timeline of research activities and academic milestones undertaken between June
2025 and September 2026 as part of the PhD focused on the CHERI Toooba architecture. It includes the refactoring of BlueSpec SystemVerilog modules and the development of a bare-metal
This section outlines a comprehensive timeline of research activities and academic milestones to be undertaken between June
2025 and September 2026 as part of the PhD to be focused on the CHERI Toooba architecture\cite{Toooba}. It includes the refactoring of BlueSpec\cite{bluespec} SystemVerilog\cite{bsv} modules and the development of a bare-metal
C benchmark suite. The work involves in-depth
debugging of the Toooba memory subsystem, the design and evaluation of in-depth analyses of the FAT allocator and performance analysis at the instruction
level. Alongside these technical efforts, the timeline reflects the structured drafting of academic publications and the ongoing development
of the PhD thesis leading to the final submission of the dissertation.
of the PhD thesis.
#+ATTR_ORG: :width 500
[[./gnatt-chart.png]]
*** June to July 2025
- Refactored BlueSpec SystemVerilog (BSV) modules within the CHERI Toooba architecture.
- Refactor BlueSpec SystemVerilog (BSV)\cite{bsv} modules within the CHERI Toooba architecture.
- Set up a bare-metal C benchmark suite for execution on the Bluespec simulation platform.
- Incorporated supervisory team feedback into revisions of the EuroSys paper.
- Undertook formal progression review requirements.
- Submitted EuroSys manuscript to the CHERI research team at the University of Glasgow for preliminary feedback.
- Incorporate supervisory team feedback into revisions of the EuroSys paper.
- Undertake formal progression review requirements.
- Submit EuroSys paper to the CHERI research team at the University of Glasgow for preliminary feedback.
*** July to August 2025
- Engaged in extensive debugging of the Toooba memory pipeline, specifically targeting the TLB bypass path.
- Finalised and validated the C benchmark suite for Toooba evaluation.
- Began technical documentation of the Toooba workflow, to support a second publication.
- Concluded revisions to the EuroSys paper by the end of July.
- Engage in extensive debugging of the Toooba memory pipeline, specifically targeting the TLB bypass path.
- Finalise and validate the C benchmark suite for the Toooba evaluation.
- Begin technical documentation of the Toooba workflow, to support a 2nd publication.
- Conclude revisions to the EuroSys paper by the end of July.
*** August to September 2025
- Continued debugging efforts within the Toooba memory subsystem.
- Drafted the abstract, introduction, and methodology sections of the second research paper.
- Aimed to generate preliminary experimental results for inclusion in the evaluation.
- Continue debugging efforts within the Toooba memory subsystem.
- Draft the abstract, introduction, and methodology sections of the second research paper.
- Aim to generate preliminary experimental results for inclusion in the evaluation for the 2nd experiment.
*** September to October 2025
- Published the EuroSys paper detailing the FAT-Pointer allocator.
- Commenced benchmarking of the Toooba design.
- Simultaneously drafted the evaluation and analysis sections of the second manuscript.
- Publish the EuroSys paper detailing the FAT-Pointer allocator.
- Commence benchmarking of the Toooba design.
- Simultaneously draft the evaluation and analysis sections of the 2nd paper.
*** October to November 2025
- Initiated third experimental phase, aimed at deeper evaluation of prior experiments.
- Modified memory allocators (TcMalloc and Mesh) to remove reliance on `mmap`.
- Initiate 3rd experimental phase, aimed at deeper evaluation of prior experiments.
- Modify memory allocators (TcMalloc and Mesh) to remove reliance on system `mmap` call.
*** November to December 2025
- Finalised second paper for peer review.
- Stripped away huge-page-specific optimisations from JeMalloc, TcMalloc, and Mesh.
- Analysed instruction-level reductions and performance implications.
- Commenced drafting of the third research paper, building on contributions from the EuroSys paper.
- Finalise 2nd paper for peer review.
- Strip away huge-page-specific optimisations from JeMalloc, TcMalloc, and Mesh.
- Analyse instruction-level reductions and performance implications.
- Commence drafting of the 3rd research paper, building on contributions from the EuroSys paper.
*** December 2025 to January 2026
- Conducted evaluation and profiling for the third paper.
- Commenced thesis chapter write-up for Experiments 1 and 2.
- Conduct evaluation and profiling for the 3rd paper.
- Commence thesis chapter write-up for Experiments 1 and 2.
*** January to September 2026
- Continued thesis development and refinement across all experimental chapters.
- Finalised and submitted third paper for peer review.
- Prepared complete PhD dissertation for submission.
- Continue thesis development and refinement across all experimental chapters.
- Finalise and submitted 3rd paper for peer review.
- Prepare complete PhD dissertation for submission.
\bibliographystyle{IEEEtran}
\bibliography{FuturePlan.bib}
** Appendix
** (Experiment 3)Allocator evaluation based on stripping instruction calls for larger allocators
#+NAME: fig:MEMALLOC
#+CAPTION: Deprecating the use of THP with CHERI bound aware embedded mmap.
[[./memory_allocator.drawio.png]]
*** Box 1 (Transparent huge pages)
#+BEGIN_COMMENT
The diagram above mentions 3 particular implementations. The first box which is the
standard THP(Transparent huge pages) utilised by modern allocators. THP initially
emphasises on doing smalled allocations and as the number of allocations grows
uses a technique which groups all smaller allocations together and when done
converts them into a large page of size 4mb in allocators such as jemalloc.
#+END_COMMENT
The diagram [[fig:MEMALLOC]] highlights three specific implementations, the
first of which is the standard Transparent Huge Pages (THP)
mechanism employed by modern memory allocators. THP initially
focuses on handling smaller memory allocations. As the volume
of allocations increases, it employs a strategy that consolidates
these smaller allocations into contiguous memory regions.
Once aggregated, these regions are subsequently converted
into larger memory pages, typically of size 4MB, as seen
in allocators like jemalloc. This approach optimises memory
management by reducing fragmentation and improving performance
through the use of larger page sizes.
#+BEGIN_COMMENT
This approach does incur addtional operations such as grouping smaller allocations
chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
huge page is created the TLB misses are reduced.
#+END_COMMENT
This approach, however, introduces additional
overhead, including the operations required to consolidate
smaller allocations and modify Translation Lookaside Buffer (TLB)
entries. These modifications can initially increase the
likelihood of TLB misses, as the process of grouping and
reorganizing memory allocations temporarily disrupts the
efficiency of TLB utilization. It is only after the
successful creation of the huge page that the benefits
materialize, leading to a reduction in TLB misses due
to the improved alignment of memory access patterns with
the larger page size.
*** Box 2 (Our current implementation)
#+BEGIN_COMMENT
Box 2 which refers to our current implementation always pre-allocates huge pages
and untilises CHERI bounds to track each allocation inside the huge page. Allowing
a single entry with the combination of bounds to provide block based behavoir in
physically contigous memory while ensuring a pointer can only access a regoin
within it's defined bounds.
#+END_COMMENT
Box 2 outlines the current implementation, which involves the
pre-allocation of huge pages and leverages CHERI
(Capability Hardware Enhanced RISC Instructions) bounds
to meticulously track each allocation within these pages.
This approach enables a single TLB entry, combined with
the precise bounds defined by CHERI capabilities, to
facilitate block-based memory management within physically
contiguous regions. By enforcing strict bounds on pointers,
the system ensures that each pointer can only access memory
within its explicitly defined region.
#+BEGIN_COMMENT
Another aspect to note is that the bounds can be of a dynamic size when defined. This is
in contrast to defining multiple page entries which need to be fixed sizes which means
they always incur multiple entries. In the current approach when the huge page size is
hit a new one is created. The limitaton of this is appraoch being we are limited to the
huge page set by the processor implementation (In our case the CHERI ARM v8.1).
#+END_COMMENT
Another critical aspect of this implementation is the
ability to define bounds of dynamic sizes, which stands
in contrast to traditional approaches that rely on
fixed-size page entries. Fixed-size entries inherently
require multiple TLB entries, regardless of the actual
memory usage, leading to inefficiencies. In the current
approach, when the allocated memory within a huge page
reaches its capacity, a new huge page is allocated.
However, a notable limitation of this method is its
dependence on the maximum huge page size supported by
the underlying processor architecture. In this case,
the system is constrained by the huge page size defined
by the CHERI-enhanced ARM v8.1\cite{noauthor_arm_nodate} architecture. While this
approach offers flexibility in memory allocation and
reduces the need for multiple TLB entries, it is
ultimately bounded by the hardware's architectural specifications.
*** Box 3 (RISC-V implementation)
#+BEGIN_COMMENT
The 3rd box specifies an alternate appraoch by not using huge pages and required
memory is not required to be physically contigous. In this approach the pointer
stores all the metadata to the translation from virtual to physical addresses.
#+END_COMMENT
The third approach, as outlined in Box 3, deviates from the
use of huge pages and does not require memory to be
physically contiguous. In this model, each pointer
is designed to store comprehensive metadata at the pointer necessary
for the translation from virtual to physical addresses.
This metadata enables the system to manage memory allocations
without the constraints of physical contiguity, thereby
offering greater flexibility in memory utilization.
By embedding translation information directly within the
pointers, this approach eliminates the need for large,
contiguous memory regions and allows for more granular
and dynamic memory management.
*** Building up from the work of Box 2 and Box 3 (Side effects we can strip away)
#+BEGIN_COMMENT
Box 2 and 3 from a high overview there is only minor difference which can be noted
which is 1 uses huge pages and other does not. Both approaches can strip down the
number intructions needed in modern allocators (Stripping away the need transitioning
from smaller to larger pages). This document is yet to give an exact breakdown.
#+END_COMMENT
From a high-level perspective, the primary distinction between
Box 2 and Box 3 lies in the use of huge pages in the former
and their absence in the latter. Both approaches share
the common advantage of reducing the number of instructions
required in modern memory allocators by eliminating the
need for transitioning between smaller and larger pages.
This simplification streamlines memory management processes.
However, this document has not yet provided a detailed breakdown
or quantitative analysis of the specific performance implications
or trade-offs.
#+BEGIN_COMMENT
As seen to the right of the diagram is a sample snippet of TC malloc from the paper
(Beyond malloc efficiency to fleet allocators). This whole span function would not
be required in our approach. The other benefit being easier get the approach by
getting mmap embedded inside the allocator.
#+END_COMMENT
As illustrated to the right of the diagram, a sample snippet of
TC malloc from the paper "Beyond malloc Efficiency to Fleet
Efficiency"\cite{FleetAllocator} is provided. In the proposed approach, the entire
span function, which is essential in TC malloc, would become
unnecessary. Additionally, the approach offers the advantage
of simplifying memory management by integrating mmap directly
within the allocator. This integration eliminates the need for
separate mechanisms to handle memory mapping.
*** Evaluation:
#+BEGIN_COMMENT
- Amount of instructions that can be stripped away from the page aware
memory allocator.
- Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
- CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
emitted vs regular ARMv8 clang program with the same allocator).
#+END_COMMENT
- The number of instructions that can be eliminated from a
page-aware memory allocator by adopting the proposed approach.
- A comparative analysis of the memory allocator's performance
using wall-clock runtime measurements, both with and without
the modified mmap implementation.
- While CHERI Purecap introduces additional instructions, such
as bounds checks, the overall approach aims to determine
whether it reduces the total number of instructions when
compared to a traditional ARMv8 Clang program using the
same allocator. This involves evaluating the trade-offs
between the overhead of CHERI-specific instructions and
the potential reductions in allocator-emitted instructions.

BIN
docs/FutureTasks/Plan/plan-1.pdf
View File

Binary file not shown.

264
docs/FutureTasks/Plan/plan-1.tex
View File

@@ -1,4 +1,4 @@
% Created 2025-06-16 Mon 15:56
% Created 2025-06-23 Mon 16:58
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
@@ -27,162 +27,282 @@
\tableofcontents
\section{Plan}
\label{sec:orgafd9b66}
\label{sec:org0b4a538}
This document outlines the proposed PhD research plan for the forthcoming academic year, building upon the outcomes and insights gained during the preceding year.
\subsection{Current experiments:}
\label{sec:orgf6e97da}
\begin{enumerate}
\item FAT allocator with huge pages.
\item FAT allocator to bypass TLB.
\item Allocator evaluation based on stripping instruction calls for larger allocators.
\end{enumerate}
\label{sec:org2ec96bb}
\begin{itemize}
\item (Experiment 1)FAT allocator with huge pages (EuroSys26 paper draft)
\item (Experiment 2)FAT allocator to bypass TLB. (Proposal of ongoing expirement)
\item (Experiment 3)Allocator evaluation based on stripping instruction calls from larger allocators. (Appendix)
\end{itemize}
\subsection{Experiment cancelled:}
\label{sec:orga64de5d}
\label{sec:orgbfb4e3d}
\begin{enumerate}
\item Uni-Kernel Development: Work scaled down to fit within the allocated PhD timeframe and introduced an extension of the FAT allocator as the third experiment.
\item Uni-Kernel Development (Reason): Work scaled down to fit within the allocated within PhD timeframe and instead introduced an extension of the FAT allocator as the third experiment.
\end{enumerate}
\subsection{Link to the Previous PhD Plan}
\label{sec:org3edf6e4}
\label{sec:org5e13e60}
\begin{itemize}
\item \url{https://github.com/Akilan1999/phd-thesis/releases/download/Year2/thesis.pdf}
\end{itemize}
\subsection{Summary of the Previous Plan}
\label{sec:orgbd2e628}
\label{sec:orgbef61d6}
\subsubsection{Phase 1: FAT-Pointer Mechanism (July–September 2024)}
\label{sec:org602d9b9}
\label{sec:orgc225731}
\begin{enumerate}
\item 1st to 15th July 2024
\label{sec:orgb53cc89}
\label{sec:orga23a507}
\begin{itemize}
\item Investigated causes of L1 TLB misses associated with contiguous memory allocation.
\item Executed performance benchmarking using COZ on selected C programs.
\item Executed performance benchmarking using COZ\cite{coz} on selected C programs.
\item Ported the kernel module to support SnMalloc, the default allocator in CheriBSD.
\end{itemize}
\item 15th to 30th July 2024
\label{sec:org7864ac1}
\label{sec:orgdcdbfff}
\begin{itemize}
\item Conducted benchmarking using the SPEC and XSBench suites.
\item Performed comparative analysis with both baseline and modified SnMalloc implementations.
\end{itemize}
\item August 2024
\label{sec:org49e9675}
\label{sec:org291b509}
\begin{itemize}
\item Initiated drafting of a paper for submission to EuroSys, focusing on the FAT-Pointer memory allocator.
\item Initiated drafting of a paper for submission to EuroSys, focusing on the FAT-Pointer memory allocator (Current: On review stage).
\end{itemize}
\item September 2024
\label{sec:org1aae812}
\label{sec:org8e3adb1}
\begin{itemize}
\item Compiled and structured thesis chapter related to the FAT-Pointer architecture.
\item Finalised and submitted the EuroSys paper.
\end{itemize}
\end{enumerate}
\subsubsection{Phase 2: RISC-V Integration (October 2024 – May 2025)}
\label{sec:org74c2673}
\label{sec:orge4d0c50}
\begin{enumerate}
\item October to December 2024
\label{sec:org6994353}
\label{sec:orge79764e}
\begin{itemize}
\item Modified the Bluespec implementation to enable TLB bypass in the memory access pipeline.
\item Configured the experimental platform and evaluation toolchain.
\item Modified the Bluespec implementation to enable TLB bypass in the memory access pipeline (Current: On progress).
\item Configured the experimental platform and evaluation toolchain (Current: On progress).
\end{itemize}
\item January to February 2025
\label{sec:org71f7755}
\label{sec:orge05fc21}
\begin{itemize}
\item Undertook experimental evaluation of the FAT-Pointer system on RISC-V (Toooba).
\item Commenced drafting of a technical paper for ISMM based on RISC-V integration results.
\item Undertook experimental evaluation of the FAT-Pointer system on RISC-V (Toooba) (Current: Todo).
\item Commenced drafting of a technical paper for ISMM based on RISC-V integration results (Current: Todo).
\end{itemize}
\item March to May 2025
\label{sec:org19387dc}
\label{sec:org90e5eee}
\begin{itemize}
\item Addressed outstanding tasks and technical backlog.
\item Continued development of the corresponding thesis chapter.
\end{itemize}
\end{enumerate}
\subsubsection{Phase 3: Uni-Kernel Deployment (May 2025 – September 2026)}
\label{sec:org4ec1211}
\label{sec:orgb30d702}
\begin{enumerate}
\item May to December 2025
\label{sec:orgebc4f5e}
\label{sec:orgd428eea}
\begin{itemize}
\item Ported the memory allocator to a CHERI-enabled Uni-Kernel environment.
\item Designed and implemented a unified memory allocator to support both kernel and user-level allocations.
\item Initiated drafting of a manuscript targeted at OSDI.
\item Ported the memory allocator to a CHERI-enabled Uni-Kernel environment (Current: Cancelled)
\item Designed and implemented a unified memory allocator to support both kernel and user-level allocations (Current: Cancelled)
\item Initiated drafting of a manuscript targeted at OSDI (Current: Cancelled)
\end{itemize}
\item January to September 2026
\label{sec:org69a9a4b}
\label{sec:orga103287}
\begin{itemize}
\item Finalised documentation and submission of the PhD thesis.
\item Submitted third research paper based on extended evaluation.
\item Finalised documentation and submission of the PhD thesis (Current: New plan to still keep these dates unchanged)
\item Submitted third research paper based on extended evaluation (Current: Replaced with "Allocator evaluation based on stripping instruction calls from larger allocators")
\end{itemize}
\end{enumerate}
\subsection{Current Research Plan}
\label{sec:org4597631}
This section outlines a comprehensive timeline of research activities and academic milestones undertaken between June
2025 and September 2026 as part of the PhD focused on the CHERI Toooba architecture. It includes the refactoring of BlueSpec SystemVerilog modules and the development of a bare-metal
\label{sec:org055ec33}
This section outlines a comprehensive timeline of research activities and academic milestones to be undertaken between June
2025 and September 2026 as part of the PhD to be focused on the CHERI Toooba architecture\cite{Toooba}. It includes the refactoring of BlueSpec\cite{bluespec} SystemVerilog\cite{bsv} modules and the development of a bare-metal
C benchmark suite. The work involves in-depth
debugging of the Toooba memory subsystem, the design and evaluation of in-depth analyses of the FAT allocator and performance analysis at the instruction
level. Alongside these technical efforts, the timeline reflects the structured drafting of academic publications and the ongoing development
of the PhD thesis leading to the final submission of the dissertation.
of the PhD thesis.
\begin{center}
\includegraphics[width=.9\linewidth]{./gnatt-chart.png}
\end{center}
\subsubsection{June to July 2025}
\label{sec:org95e44ac}
\label{sec:org2f8419d}
\begin{itemize}
\item Refactored BlueSpec SystemVerilog (BSV) modules within the CHERI Toooba architecture.
\item Refactor BlueSpec SystemVerilog (BSV)\cite{bsv} modules within the CHERI Toooba architecture.
\item Set up a bare-metal C benchmark suite for execution on the Bluespec simulation platform.
\item Incorporated supervisory team feedback into revisions of the EuroSys paper.
\item Undertook formal progression review requirements.
\item Submitted EuroSys manuscript to the CHERI research team at the University of Glasgow for preliminary feedback.
\item Incorporate supervisory team feedback into revisions of the EuroSys paper.
\item Undertake formal progression review requirements.
\item Submit EuroSys paper to the CHERI research team at the University of Glasgow for preliminary feedback.
\end{itemize}
\subsubsection{July to August 2025}
\label{sec:org3309e51}
\label{sec:org18e2368}
\begin{itemize}
\item Engaged in extensive debugging of the Toooba memory pipeline, specifically targeting the TLB bypass path.
\item Finalised and validated the C benchmark suite for Toooba evaluation.
\item Began technical documentation of the Toooba workflow, to support a second publication.
\item Concluded revisions to the EuroSys paper by the end of July.
\item Engage in extensive debugging of the Toooba memory pipeline, specifically targeting the TLB bypass path.
\item Finalise and validate the C benchmark suite for the Toooba evaluation.
\item Begin technical documentation of the Toooba workflow, to support a 2nd publication.
\item Conclude revisions to the EuroSys paper by the end of July.
\end{itemize}
\subsubsection{August to September 2025}
\label{sec:orgd4ef96b}
\label{sec:org8f7cc7e}
\begin{itemize}
\item Continued debugging efforts within the Toooba memory subsystem.
\item Drafted the abstract, introduction, and methodology sections of the second research paper.
\item Aimed to generate preliminary experimental results for inclusion in the evaluation.
\item Continue debugging efforts within the Toooba memory subsystem.
\item Draft the abstract, introduction, and methodology sections of the second research paper.
\item Aim to generate preliminary experimental results for inclusion in the evaluation for the 2nd experiment.
\end{itemize}
\subsubsection{September to October 2025}
\label{sec:orged09227}
\label{sec:orgaeda479}
\begin{itemize}
\item Published the EuroSys paper detailing the FAT-Pointer allocator.
\item Commenced benchmarking of the Toooba design.
\item Simultaneously drafted the evaluation and analysis sections of the second manuscript.
\item Publish the EuroSys paper detailing the FAT-Pointer allocator.
\item Commence benchmarking of the Toooba design.
\item Simultaneously draft the evaluation and analysis sections of the 2nd paper.
\end{itemize}
\subsubsection{October to November 2025}
\label{sec:org4041d7a}
\label{sec:org5c3273b}
\begin{itemize}
\item Initiated third experimental phase, aimed at deeper evaluation of prior experiments.
\item Modified memory allocators (TcMalloc and Mesh) to remove reliance on `mmap`.
\item Initiate 3rd experimental phase, aimed at deeper evaluation of prior experiments.
\item Modify memory allocators (TcMalloc and Mesh) to remove reliance on system `mmap` call.
\end{itemize}
\subsubsection{November to December 2025}
\label{sec:org5a08a2c}
\label{sec:org3157e97}
\begin{itemize}
\item Finalised second paper for peer review.
\item Stripped away huge-page-specific optimisations from JeMalloc, TcMalloc, and Mesh.
\item Analysed instruction-level reductions and performance implications.
\item Commenced drafting of the third research paper, building on contributions from the EuroSys paper.
\item Finalise 2nd paper for peer review.
\item Strip away huge-page-specific optimisations from JeMalloc, TcMalloc, and Mesh.
\item Analyse instruction-level reductions and performance implications.
\item Commence drafting of the 3rd research paper, building on contributions from the EuroSys paper.
\end{itemize}
\subsubsection{December 2025 to January 2026}
\label{sec:org2e22325}
\label{sec:org0b82dc3}
\begin{itemize}
\item Conducted evaluation and profiling for the third paper.
\item Commenced thesis chapter write-up for Experiments 1 and 2.
\item Conduct evaluation and profiling for the 3rd paper.
\item Commence thesis chapter write-up for Experiments 1 and 2.
\end{itemize}
\subsubsection{January to September 2026}
\label{sec:orga5d12a0}
\label{sec:org1cc5f31}
\begin{itemize}
\item Continued thesis development and refinement across all experimental chapters.
\item Finalised and submitted third paper for peer review.
\item Prepared complete PhD dissertation for submission.
\item Continue thesis development and refinement across all experimental chapters.
\item Finalise and submitted 3rd paper for peer review.
\item Prepare complete PhD dissertation for submission.
\end{itemize}
\bibliographystyle{IEEEtran}
\bibliography{FuturePlan.bib}
\subsection{Appendix}
\label{sec:orgfc26bd9}
\subsection{(Experiment 3)Allocator evaluation based on stripping instruction calls for larger allocators}
\label{sec:orgae488c8}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./memory_allocator.drawio.png}
\caption{\label{fig:org51a01ee}Deprecating the use of THP with CHERI bound aware embedded mmap.}
\end{figure}
\subsubsection{Box 1 (Transparent huge pages)}
\label{sec:org4622604}
The diagram \ref{fig:org51a01ee} highlights three specific implementations, the
first of which is the standard Transparent Huge Pages (THP)
mechanism employed by modern memory allocators. THP initially
focuses on handling smaller memory allocations. As the volume
of allocations increases, it employs a strategy that consolidates
these smaller allocations into contiguous memory regions.
Once aggregated, these regions are subsequently converted
into larger memory pages, typically of size 4MB, as seen
in allocators like jemalloc. This approach optimises memory
management by reducing fragmentation and improving performance
through the use of larger page sizes.
This approach, however, introduces additional
overhead, including the operations required to consolidate
smaller allocations and modify Translation Lookaside Buffer (TLB)
entries. These modifications can initially increase the
likelihood of TLB misses, as the process of grouping and
reorganizing memory allocations temporarily disrupts the
efficiency of TLB utilization. It is only after the
successful creation of the huge page that the benefits
materialize, leading to a reduction in TLB misses due
to the improved alignment of memory access patterns with
the larger page size.
\subsubsection{Box 2 (Our current implementation)}
\label{sec:org6f3a3db}
Box 2 outlines the current implementation, which involves the
pre-allocation of huge pages and leverages CHERI
(Capability Hardware Enhanced RISC Instructions) bounds
to meticulously track each allocation within these pages.
This approach enables a single TLB entry, combined with
the precise bounds defined by CHERI capabilities, to
facilitate block-based memory management within physically
contiguous regions. By enforcing strict bounds on pointers,
the system ensures that each pointer can only access memory
within its explicitly defined region.
Another critical aspect of this implementation is the
ability to define bounds of dynamic sizes, which stands
in contrast to traditional approaches that rely on
fixed-size page entries. Fixed-size entries inherently
require multiple TLB entries, regardless of the actual
memory usage, leading to inefficiencies. In the current
approach, when the allocated memory within a huge page
reaches its capacity, a new huge page is allocated.
However, a notable limitation of this method is its
dependence on the maximum huge page size supported by
the underlying processor architecture. In this case,
the system is constrained by the huge page size defined
by the CHERI-enhanced ARM v8.1\cite{noauthor_arm_nodate} architecture. While this
approach offers flexibility in memory allocation and
reduces the need for multiple TLB entries, it is
ultimately bounded by the hardware's architectural specifications.
\subsubsection{Box 3 (RISC-V implementation)}
\label{sec:org71d9f3b}
The third approach, as outlined in Box 3, deviates from the
use of huge pages and does not require memory to be
physically contiguous. In this model, each pointer
is designed to store comprehensive metadata at the pointer necessary
for the translation from virtual to physical addresses.
This metadata enables the system to manage memory allocations
without the constraints of physical contiguity, thereby
offering greater flexibility in memory utilization.
By embedding translation information directly within the
pointers, this approach eliminates the need for large,
contiguous memory regions and allows for more granular
and dynamic memory management.
\subsubsection{Building up from the work of Box 2 and Box 3 (Side effects we can strip away)}
\label{sec:org08d4ac7}
From a high-level perspective, the primary distinction between
Box 2 and Box 3 lies in the use of huge pages in the former
and their absence in the latter. Both approaches share
the common advantage of reducing the number of instructions
required in modern memory allocators by eliminating the
need for transitioning between smaller and larger pages.
This simplification streamlines memory management processes.
However, this document has not yet provided a detailed breakdown
or quantitative analysis of the specific performance implications
or trade-offs.
As illustrated to the right of the diagram, a sample snippet of
TC malloc from the paper "Beyond malloc Efficiency to Fleet
Efficiency"\cite{FleetAllocator} is provided. In the proposed approach, the entire
span function, which is essential in TC malloc, would become
unnecessary. Additionally, the approach offers the advantage
of simplifying memory management by integrating mmap directly
within the allocator. This integration eliminates the need for
separate mechanisms to handle memory mapping.
\subsubsection{Evaluation:}
\label{sec:org2a1bb59}
\begin{itemize}
\item The number of instructions that can be eliminated from a
page-aware memory allocator by adopting the proposed approach.
\item A comparative analysis of the memory allocator's performance
using wall-clock runtime measurements, both with and without
the modified mmap implementation.
\item While CHERI Purecap introduces additional instructions, such
as bounds checks, the overall approach aims to determine
whether it reduces the total number of instructions when
compared to a traditional ARMv8 Clang program using the
same allocator. This involves evaluating the trade-offs
between the overhead of CHERI-specific instructions and
the potential reductions in allocator-emitted instructions.
\end{itemize}
\end{document}

BIN
docs/RISCV-FAT/.DS_Store vendored
View File

Binary file not shown.

2
docs/RISCV-FAT/Paper/paper.org
View File

@@ -40,7 +40,7 @@ potentially enhancing the capabilities of the memory management system.
*** Implementation
The figure [[fig:CSTOOOBA]] above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture.
On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that will need to do to the
On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that we will need to do to the
memory pipeline in order to bypass the use of the Data TLB and instead utilise the offset from the pointer. The primary focus will be
on the memory pipeline.\\

BIN
docs/RISCV-FAT/Paper/paper.pdf
View File

Binary file not shown.

32
docs/RISCV-FAT/Paper/paper.tex
View File

@@ -1,4 +1,4 @@
% Created 2025-06-18 Wed 19:38
% Created 2025-06-18 Wed 19:47
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
@@ -27,10 +27,10 @@
\tableofcontents
\section{FAT Allocator without the TLB}
\label{sec:orga2b6014}
\label{sec:orga3b6b50}
\subsection{Abstract}
\label{sec:orgca71060}
\label{sec:org5961619}
This document explores an extension of the FAT allocator approach to memory management in RISC-V Toooba\cite{rugg_2022}.
CHERI introduces a fine-grained memory protection mechanism by embedding bounds and permissions directly
within pointers. Leveraging this model, we propose a system in which offsets are stored within the pointer itself, enabling
@@ -38,17 +38,17 @@ direct memory access without reliance on traditional address translation mechani
facilitates the design of a block-based memory allocator within physically contiguous memory. The sections expanded below
are the technique expected to be used and the evaluation criteria for the following experiment.
\subsection{Research questions}
\label{sec:org7ae1821}
\label{sec:orge1b3555}
\begin{enumerate}
\item How can embedding offsets within a FAT pointer (i.e CHERI pointer) improve memory accesses for a block-based allocator for the RISC-V CHERI modified Toooba architecture ?
\item To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency ?
\end{enumerate}
\subsection{Proposed approach}
\label{sec:org8425c43}
\label{sec:orga716280}
\begin{figure}[htbp]
\centering
\includegraphics[width=300px]{./diagram/MainOverview.png}
\caption{\label{fig:orgb6d2903}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
\caption{\label{fig:orgf01f491}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
\end{figure}
FAT-Pointers based range addresses, combined with the capabilities of the CHERI architecture, introduce
@@ -64,19 +64,19 @@ over memory regions. The functionality of ranges encompasses several key aspects
\item Instrumenting Block-Based Allocators with the FAT Pointer.
\end{itemize}
In figure \ref{fig:orgb6d2903}, the green-highlighted section marks the unused space between the 48th and 64th bits
In figure \ref{fig:orgf01f491}, the green-highlighted section marks the unused space between the 48th and 64th bits
within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata,
potentially enhancing the capabilities of the memory management system.
\begin{figure}[htbp]
\centering
\includegraphics[width=500px]{./diagram/Toooba-codesnippet.png}
\caption{\label{fig:org54bca80}Toooba processor with pseudo code change to bypass DataTLB.}
\caption{\label{fig:org8363643}Toooba processor with pseudo code change to bypass DataTLB.}
\end{figure}
\subsubsection{Implementation}
\label{sec:org51348f1}
The figure \ref{fig:org54bca80} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture.
On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that will need to do to the
\label{sec:org4e24323}
The figure \ref{fig:org8363643} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture.
On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that we will need to do to the
memory pipeline in order to bypass the use of the Data TLB and instead utilise the offset from the pointer. The primary focus will be
on the memory pipeline.\\
@@ -102,20 +102,20 @@ returned data written to the appropriate physical register. Generally, the memor
the new access types, incorporate the Data TLB bypass mechanism, and include the necessary capability checks to ensure that accesses
are properly authorised.
\subsection{Proposed evaluation}
\label{sec:orgd48ec63}
\label{sec:orgc0caeea}
The evaluation of the proposed FAT allocator implemented using CHERI-enhanced pointers on the RISC-V Toooba architecture
aims to assess both its performance characteristics and architectural implications, particularly in the context of removing
the Translation Lookaside Buffer (TLB) from the memory access pathway. The evaluation methodology is designed to address
the research questions with a focus on improvements in memory access and reductions in
latency for address translation.
\subsubsection{BlueSpec simulator}
\label{sec:org7a60e2a}
\label{sec:org2206786}
To evaluate the proposed FAT pointer based memory management architecture, we plan to conduct simulations using the
Bluespec SystemVerilog (BSV)\cite{bsv} framework. Bluespec provides a cycle-accurate hardware simulation environment that
allows precise modelling of architectural behaviour, including custom memory pipelines, capability checking, and
physical address translation bypass mechanisms.
\subsubsection{Performance Metrics}
\label{sec:org3ab69c0}
\label{sec:orgf6cbf89}
To quantify the performance benefits of the proposed system, the following metrics will be investigated:
@@ -135,7 +135,7 @@ An analysis of the number of instructions executed during allocation, deallocati
determine whether the additional logic required for handling FAT pointers introduces meaningful overhead.
\end{itemize}
\subsubsection{System Resource Utilisation}
\label{sec:org2a44a34}
\label{sec:org629ea18}
\begin{itemize}
\item \textbf{Cache behaviour}
@@ -147,7 +147,7 @@ Although the system does not utilise a TLB, comparative analysis will be perform
the performance cost typically incurred through TLB misses, thereby contextualising the advantage of their removal.
\end{itemize}
\subsubsection{Benchmarking Against Baseline Architectures}
\label{sec:orgc282a3a}
\label{sec:orgb71ca58}
A series of micro and macro benchmarks will be employed to compare the FAT allocator with traditional memory allocators that rely on virtual
memory and TLBs. Micro benchmarks will include fine-grained tests of memory operations, while macro benchmarks will involve application-level

BIN
docs/RISCV-FAT/Paper/riscv-proposal.pdf Normal file
View File

Binary file not shown.