diff --git a/docs/EuroSys/Paper/paper.aux b/docs/EuroSys/Paper/paper.aux index 23b5178..5dfb67f 100644 --- a/docs/EuroSys/Paper/paper.aux +++ b/docs/EuroSys/Paper/paper.aux @@ -64,8 +64,8 @@ \@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Experiment setup}{5}{subsection.5.1}\protected@file@percent } \newlabel{sec:Experiment}{{5.1}{5}{Experiment setup}{subsection.5.1}{}} \@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Benchmarks}{5}{subsection.5.2}\protected@file@percent } -\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Micro benchmark}{5}{subsubsection.5.2.1}\protected@file@percent } \newlabel{sec:Micro}{{5.2.1}{5}{Micro benchmark}{subsubsection.5.2.1}{}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Micro benchmark}{5}{subsubsection.5.2.1}\protected@file@percent } \newlabel{sec:Macro}{{5.2.2}{5}{Macro benchmark}{subsubsection.5.2.2}{}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.2}Macro benchmark}{5}{subsubsection.5.2.2}\protected@file@percent } \@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Results}{6}{subsection.5.3}\protected@file@percent } diff --git a/docs/EuroSys/Paper/paper.fdb_latexmk b/docs/EuroSys/Paper/paper.fdb_latexmk index a7cf8d1..94b17e0 100644 --- a/docs/EuroSys/Paper/paper.fdb_latexmk +++ b/docs/EuroSys/Paper/paper.fdb_latexmk @@ -1,13 +1,13 @@ # Fdb version 4 -["bibtex paper"] 1745154910.17453 "paper.aux" "paper.bbl" "paper" 1745154911.75342 0 +["bibtex paper"] 1745224532.08591 "paper.aux" "paper.bbl" "paper" 1745224533.70736 0 "./paperReferences.bib" 1745154876.64218 46828 b3c7e70331098da6a7fbd68e2a4277a3 "" "/usr/local/texlive/2025/texmf-dist/bibtex/bst/base/unsrt.bst" 1292289607 18030 1376b4b231b50c66211e47e42eda2875 "" - "paper.aux" 1745154911.45033 7767 2d2fd3c4d1929deee7aebd01524eab86 "pdflatex" + "paper.aux" 1745224533.40044 7767 c3c79e09db5ac00f42873e8ffbd9b68a "pdflatex" (generated) "paper.bbl" "paper.blg" (rewritten before read) -["pdflatex"] 1745154910.25767 "paper.tex" "paper.pdf" "paper" 1745154911.75354 0 +["pdflatex"] 1745224532.17335 "paper.tex" "paper.pdf" "paper" 1745224533.70749 0 "/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc" 1558214095 7693 0f2dce6d313c82989ec3a67fc24df2a0 "" "/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_25tcsq.enc" 1490131464 2921 8ca0eb0831f9bc5da080d3697cfe67bf "" "/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_76gpa5.enc" 1490131464 2933 9ad527ce78d7c5fa0a642dead095f172 "" @@ -219,10 +219,10 @@ "diagram/TLBAccess.drawio.png" 1744196148.80543 77522 75367f218335fe386db852966a892e9b "" "diagram/bargraph.png" 1744196148.80607 74263 65509d21744edc6c9ca02b8c67d664fb "" "diagram/kmeans.png" 1744196148.80901 94217 5d14308c169ff296bf499805b9823aa6 "" - "paper.aux" 1745154911.45033 7767 2d2fd3c4d1929deee7aebd01524eab86 "pdflatex" - "paper.bbl" 1745154910.25468 4124 00c91189ca7ebb5f2c50a354246b9795 "bibtex paper" - "paper.out" 1745154911.45126 3243 8666c5d883f1c403037236be395fbf0f "pdflatex" - "paper.tex" 1745154895.44511 84391 d1ac283cc14bbae16162b54e4807a57b "" + "paper.aux" 1745224533.40044 7767 c3c79e09db5ac00f42873e8ffbd9b68a "pdflatex" + "paper.bbl" 1745224532.17051 4124 00c91189ca7ebb5f2c50a354246b9795 "bibtex paper" + "paper.out" 1745224533.40129 3243 8666c5d883f1c403037236be395fbf0f "pdflatex" + "paper.tex" 1745224518.39528 84132 33b106b0947466adbb9bc7c72ae34180 "" (generated) "paper.aux" "paper.log" diff --git a/docs/EuroSys/Paper/paper.log b/docs/EuroSys/Paper/paper.log index f61a38d..0a69393 100644 --- a/docs/EuroSys/Paper/paper.log +++ b/docs/EuroSys/Paper/paper.log @@ -1,4 +1,4 @@ -This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 20 APR 2025 14:15 +This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 21 APR 2025 09:35 entering extended mode restricted \write18 enabled. %&-line parsing enabled. @@ -1207,64 +1207,61 @@ LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be LaTeX Font Info: Font shape `U/ntxexa/m/n' will be (Font) scaled to size 9.0pt on input line 359. -Underfull \vbox (badness 4913) has occurred while \output is active [] - - LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 6.0pt on input line 394. +(Font) scaled to size 6.0pt on input line 391. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 36.135pt on input line 394. -LaTeX Font Info: Calculating math sizes for size <36.135> on input line 394. +(Font) scaled to size 36.135pt on input line 391. +LaTeX Font Info: Calculating math sizes for size <36.135> on input line 391. LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `OT1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `OML/nxlmi/m/it' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `LMS/ntxsy/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `LMX/ntxexx/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `U/ntxmia/m/it' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `U/ntxmia/m/it' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `U/ntxmia/m/it' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `U/ntxsym/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `U/ntxsym/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `U/ntxsym/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `U/ntxsyc/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. LaTeX Font Info: Font shape `U/ntxexa/m/n' will be -(Font) scaled to size 36.135pt on input line 394. +(Font) scaled to size 36.135pt on input line 391. LaTeX Font Info: Font shape `U/ntxexa/m/n' will be -(Font) scaled to size 26.37839pt on input line 394. +(Font) scaled to size 26.37839pt on input line 391. LaTeX Font Info: Font shape `U/ntxexa/m/n' will be -(Font) scaled to size 19.87434pt on input line 394. +(Font) scaled to size 19.87434pt on input line 391. [1.1{/usr/local/texlive/2025/texmf-var/fonts/map/pdftex/updmap/pdftex.map}{/usr /local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_76gpa5.enc}{/usr/ local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_25tcsq.enc}{/usr/l @@ -1278,42 +1275,42 @@ ocal/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_naooyc.enc} File: diagram/HighOverviewArchitecture.drawio.png Graphic file (type png) Package pdftex.def Info: diagram/HighOverviewArchitecture.drawio.png used on i -nput line 514. +nput line 511. (pdftex.def) Requested size: 303.78008pt x 236.93262pt. -Class acmart Warning: A possible image without description on input line 518. +Class acmart Warning: A possible image without description on input line 515. LaTeX Warning: `h' float specifier changed to `ht'. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be -(Font) scaled to size 9.0pt on input line 520. +(Font) scaled to size 9.0pt on input line 517. LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be -(Font) scaled to size 9.0pt on input line 526. +(Font) scaled to size 9.0pt on input line 523. LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be -(Font) scaled to size 7.0pt on input line 526. +(Font) scaled to size 7.0pt on input line 523. [2.2] File: diagram/AllocationOverview24.png Graphic file (type png) Package pdftex.def Info: diagram/AllocationOverview24.png used on input line 5 -43. +40. (pdftex.def) Requested size: 202.51491pt x 140.43979pt. -Class acmart Warning: A possible image without description on input line 546. +Class acmart Warning: A possible image without description on input line 543. File: diagram/TLBAccess.drawio.png Graphic file (type png) -Package pdftex.def Info: diagram/TLBAccess.drawio.png used on input line 619. +Package pdftex.def Info: diagram/TLBAccess.drawio.png used on input line 616. (pdftex.def) Requested size: 202.51491pt x 247.43411pt. -Class acmart Warning: A possible image without description on input line 622. +Class acmart Warning: A possible image without description on input line 619. Underfull \vbox (badness 10000) has occurred while \output is active [] @@ -1323,13 +1320,13 @@ Underfull \vbox (badness 10000) has occurred while \output is active [] [3.3 <./diagram/HighOverviewArchitecture.drawio.png> <./diagram/AllocationOverv iew24.png>] Package hyperref Info: bookmark level for unknown algorithm defaults to 0 on in -put line 675. +put line 672. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/sc' will be -(Font) scaled to size 9.0pt on input line 678. +(Font) scaled to size 9.0pt on input line 675. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 6.6pt on input line 679. +(Font) scaled to size 6.6pt on input line 676. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be -(Font) scaled to size 5.5pt on input line 679. +(Font) scaled to size 5.5pt on input line 676. @@ -1337,22 +1334,22 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be [4.4{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_ncsllp.e nc}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_oexx6f.en c} <./diagram/TLBAccess.drawio.png>] -Overfull \hbox (2.40372pt too wide) in paragraph at lines 753--757 -\T1/LinuxLibertineT-TLF/m/n/9 (-20) loc [[]], Je-mal-loc is the de-fault mem-or -y al-lo-ca-tor for CHERIBSD [[]], +Overfull \hbox (2.01144pt too wide) in paragraph at lines 750--753 +\T1/LinuxLibertineT-TLF/m/n/9 (-20) loc [[]]. Je-mal-loc is the de-fault mem-or +y al-lo-ca-tor for CHERIBSD [[]]. [] LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/it' will be -(Font) scaled to size 9.0pt on input line 865. -LaTeX Font Info: Trying to load font information for T1+zi4 on input line 87 -4. +(Font) scaled to size 9.0pt on input line 867. +LaTeX Font Info: Trying to load font information for T1+zi4 on input line 86 +8. (/usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd File: t1zi4.fd 2018/01/14 T1/zi4 (Inconsolata) ) LaTeX Font Info: Font shape `T1/zi4/m/n' will be -(Font) scaled to size 9.0pt on input line 874. +(Font) scaled to size 9.0pt on input line 868. Package microtype Info: Loading generic protrusion settings for font family (microtype) `zi4' (encoding: T1). (microtype) For optimal results, create family-specific settings. @@ -1360,20 +1357,22 @@ Package microtype Info: Loading generic protrusion settings for font family File: diagram/bargraph.png Graphic file (type png) -Package pdftex.def Info: diagram/bargraph.png used on input line 917. +Package pdftex.def Info: diagram/bargraph.png used on input line 911. (pdftex.def) Requested size: 455.6624pt x 284.78517pt. -Class acmart Warning: A possible image without description on input line 919. +Class acmart Warning: A possible image without description on input line 913. + + +LaTeX Warning: `h' float specifier changed to `ht'. + + +Underfull \vbox (badness 2088) has occurred while \output is active [] [5.5{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc }] - -LaTeX Warning: `h' float specifier changed to `ht'. - - Underfull \vbox (badness 10000) has occurred while \output is active [] @@ -1387,15 +1386,18 @@ Underfull \vbox (badness 10000) has occurred while \output is active [] <./diagram/kmeans.png, id=207, 1011.78pt x 578.16pt> File: ./diagram/kmeans.png Graphic file (type png) -Package pdftex.def Info: ./diagram/kmeans.png used on input line 967. +Package pdftex.def Info: ./diagram/kmeans.png used on input line 961. (pdftex.def) Requested size: 265.2637pt x 151.57959pt. -Overfull \hbox (24.11621pt too wide) in paragraph at lines 967--968 +Overfull \hbox (24.11621pt too wide) in paragraph at lines 961--962 [][] [] -Class acmart Warning: A possible image without description on input line 969. +Class acmart Warning: A possible image without description on input line 963. + + +Underfull \vbox (badness 2096) has occurred while \output is active [] @@ -1404,13 +1406,7 @@ Underfull \vbox (badness 10000) has occurred while \output is active [] -[7.7 <./diagram/bargraph.png> <./diagram/kmeans.png>] -Overfull \hbox (1.25471pt too wide) in paragraph at lines 1013--1017 -[]\T1/LinuxLibertineT-TLF/m/n/9 (-20) While the al-lo-ca-tor ex-cels in sce-nar --ios em-pha-siz-ing high-memory - [] - -(./paper.bbl +[7.7 <./diagram/bargraph.png> <./diagram/kmeans.png>] (./paper.bbl Underfull \hbox (badness 2443) in paragraph at lines 91--93 @@ -1449,13 +1445,13 @@ Package rerunfilecheck Info: File `paper.out' has not changed. (rerunfilecheck) Checksum: 8666C5D883F1C403037236BE395FBF0F;3243. ) Here is how much of TeX's memory you used: - 24052 strings out of 473190 - 394523 string characters out of 5715801 - 967612 words of memory out of 5000000 + 24043 strings out of 473190 + 394298 string characters out of 5715801 + 968614 words of memory out of 5000000 46201 multiletter control sequences out of 15000+600000 - 776962 words of font info for 460 fonts, out of 8000000 for 9000 + 775822 words of font info for 454 fonts, out of 8000000 for 9000 1302 hyphenation exceptions out of 8191 - 90i,17n,131p,1002b,645s stack positions out of 10000i,1000n,20000p,200000b,200000s + 90i,16n,131p,1002b,645s stack positions out of 10000i,1000n,20000p,200000b,200000s -Output written on paper.pdf (8 pages, 710830 bytes). +Output written on paper.pdf (8 pages, 710646 bytes). PDF statistics: 293 PDF objects out of 1000 (max. 8388607) 244 compressed objects within 3 object streams diff --git a/docs/EuroSys/Paper/paper.pdf b/docs/EuroSys/Paper/paper.pdf index e02ce78..e55fda2 100644 Binary files a/docs/EuroSys/Paper/paper.pdf and b/docs/EuroSys/Paper/paper.pdf differ diff --git a/docs/EuroSys/Paper/paper.tex b/docs/EuroSys/Paper/paper.tex index 8d6ca41..e767def 100644 --- a/docs/EuroSys/Paper/paper.tex +++ b/docs/EuroSys/Paper/paper.tex @@ -368,7 +368,7 @@ memory allocations. The contributions for the following paper are as follows: (Section ~\ref{sec:MemoryAllocator}). \end{itemize} -Through comprehensive evaluation including micro and macro benchmarks, we demonstrate the allocator's ability +Through comprehensive evaluation including micro and macro benchmarks, we demonstrate the allocators ability to reduce TLB misses by up to 90\% which yields in significant improvements in wall clock runtimes for memory-intensive applications. While its impact on larger and computation-heavy workloads is less pronounced. The proposed allocator shows strong potential for advancing memory management in scenarios requiring @@ -434,10 +434,10 @@ handler then searches the RTLB for the missed address. If found, generates a new TLB entry with the physical address derived from the base virtual address and range offset along with the permission bits. If the RTLB also misses, the system defaults to a standard page walk while a range table walker simultaneously -loads the range into the RTLB in the background, avoiding delays in-memory operations. -The RTLB, functioning as a fully associative search structure, ensures -that most last-level TLB misses are handled efficiently by range mapping, -reducing the need for costly page table walks. +loads the range into the RTLB on the background. This avoids delays for in-memory operations. +The RTLB functions as a fully associative search structure ensuring +that most last-level TLB misses are handled efficiently by range mapping which +reduces the need for costly page table walks. \subsection{CHERI} \label{sec:orgbf2eaac} @@ -460,18 +460,17 @@ CHERI extends conventional processor Instruction-Set Architectures (ISAs) with architectural capabilities to enable fine-grained memory protection and highly scalable software compartmentalisation. It is a hybrid capability architecture that can combine capabilities with conventional MMU (Memory Management Unit) -based systems. The contributions of CHERI include ISA changes to introduce architectural -capabilities; a new microarchitecture that demonstrates capabilities can be implemented efficiently in hardware, -with support for efficient tagged memory to protect capabilities and compress them to reduce memory overhead; -a newly designed software construction model that uses capabilities to provide fine-grained memory protection and scalable -software compartmentalisation; language and compiler extensions for using capabilities with C and C++; and OS extensions to -support fine-grained memory protection (including spatial, referential, and non-stack temporal memory safety) and abstraction extensions +based systems. The contributions of CHERI includes ISA changes to introduce architectural +capabilities and is a new microarchitecture which shows that capabilities can be implemented efficiently in hardware. +CHERI provides support for efficient tagged memory to protect capabilities and compresses them to reduce memory overhead. +The CHERI ecosystem provides language and compiler extensions for using capabilities with C and C++. An OS extensions is also +provided to support fine-grained memory protection (including spatial, referential, and non-stack temporal memory safety) and abstraction extensions for scalable software compartmentalisation. \subsection{CHERI CC} -CHERI Concentrate: Practical Compressed Capabilities\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI, aims to address the performance and compatibility challenges associated with +CHERI Concentrate: Practical Compressed Capabilities\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI that aims to address the performance and compatibility challenges associated with capability pointers. Capability pointers enhance memory safety by embedding bounds and permissions directly -within pointers, but traditional implementations double their size—leading to increased memory usage. CHERI CC +within pointers. Traditional implementations of CHERI double their size—leading in bounds to increased memory usage. CHERI CC proposes a compression strategy that preserves security while reducing size and inefficiencies. Key contributions include a floating-point bound encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimised space usage for larger ones. @@ -515,12 +514,12 @@ in this implementation is the use of range addresses with CHERI CC~\cite{woodruf % \end{minipage} \end{figure*} -Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (\textit{malloc()}) and a proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit +Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (\textit{malloc()}) and the proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit virtual addresses and a TLB walker (L1, L2 and L3 cache) to achieve non-contiguous allocation in physical memory. This typically results in more TLB entries and increased TLB misses increasing the reasoning to have more TLB walks. In contrast, the FAT Address Translations method employs a custom allocator leveraging physically contiguous memory by using CHERI to encode -bounds within the pointers and as shown in the figure \ref{fig:HighOverviewArchitecture} there is almost no reliance on walking the TLB hierarchy. +bounds within the pointers and as shown in the figure \ref{fig:HighOverviewArchitecture} (there is almost no reliance on walking the TLB hierarchy). % Figure \ref{fig:HighOverviewArchitecture} illustrates % the methodology employed to use the CHERI @@ -552,11 +551,11 @@ FAT memory ranges are established using bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019}. % as referred in section ~\ref{sec:128bitCompressedBounds}. -Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single, -large contiguous memory area, or huge page. Within this huge page, the orange and blue lines indicate +Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single +large contiguous memory area or huge page. Within this huge page the orange and blue lines indicate two separate memory allocations equivalent to invoking \textit{malloc} twice to allocate memory in distinct regions. This scenario simulates a block-based memory allocator operating within the confines of a huge page. -The allocations use the bounds encoded in the FAT, ensuring tracking of the allocated memory regions. +The allocations use the bounds encoded in FAT which ensures tracking of the allocated memory regions. By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page. \subsection{128 bit compressed bounds} @@ -655,12 +654,12 @@ on physically contiguous memory. \section{Memory allocator design} \label{sec:MemoryAllocator} -This section presents a straightforward memory allocator designed and implemented based on the +This section presents a straightforward memory allocator designed and is implemented based on the principles outlined in FAT (Section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: \textit{InitAlloc}, \textit{malloc}, and \textit{free}. The \textit{InitAlloc} function initialises the memory pool, setting up the necessary data structures and metadata required for efficient memory management. The \textit{malloc} function is -responsible for allocating a contiguous block of memory of a specified size, while the \textit{free} -function deallocates the memory, returning it to the pool for future use. +responsible for allocating a contiguous block of memory of a specified size. When the \textit{free} +function deallocates memory it is returned to the pool for future use. % A notable feature of this malloc implementation is its compatibility with kernel modules, % where it can be integrated as an alternative to the mmap system call. This integration @@ -684,15 +683,15 @@ function deallocates the memory, returning it to the pool for future use. \end{algorithm} When the \textit{malloc} function (Algorithm \ref{alg:malloc}) is invoked, the algorithm employs an eager allocation strategy for physical memory. -This is achieved through the use of the SetBounds mechanism, which constructs a FAT-specialised +This is achieved through the use of the SetBounds mechanism. This constructs a FAT-specialised pointer that encodes both the start and end addresses of the allocated memory region within the pointer itself. The start and end addresses correspond to the size of the memory block requested by \textit{malloc}. This approach introduces a method of memory tracking, where the bounds of the allocated region is -explicitly encoded in the address, enabling efficient monitoring and management of memory usage. +explicitly encoded in the address which enables efficient monitoring and management of memory usage. Furthermore, this design uses shared huge page TLB entries to map and track memory addresses. By encoding bounds directly into the address, the algorithm ensures that memory -accesses remain within the allocated region, thereby reducing the risk of out-of-bounds +accesses remain within the allocated region. Thereby reducing the risk of out-of-bounds errors. This use of FAT and shared TLB entries not only align with the principles of efficient memory management but also demonstrate a practical use case of huge pages in CHERI. @@ -709,8 +708,8 @@ efficient memory management but also demonstrate a practical use case of huge pa The memory deallocation (Algorithm \ref{alg:free}) mechanism in the proposed allocator is facilitated by the FAT structure introduced in the \textit{malloc} algorithm. When the \textit{free} function is invoked, it uses the metadata - embedded within the FAT to determine the range and size of the allocated memory region. - Specifically, FAT encodes the start and end addresses of each allocation, providing the information needed to + embedded within FAT to determine the range and size of the allocated memory region. + Specifically, FAT encodes the start and end addresses of each allocation and provides the information needed to identify the memory block to be deallocated. This enables the allocator to accurately unmap the corresponding memory region from the address space. @@ -738,27 +737,26 @@ efficient memory management but also demonstrate a practical use case of huge pa \end{algorithmic} \end{algorithm} - Algorithm \ref{alg:initAlloc} describes the initialisation of physically contiguous memory through the use of huge pages, -a mechanism supported by modern architectures to optimise memory management. The algorithm begins by -allocating a fixed block of 1 GB of physically contiguous memory. This decision is driven by the -architectural constraints of contemporary systems, particularly ARM-based CPUs, where 1 GB represents + Algorithm \ref{alg:initAlloc} describes the initialisation of physically contiguous memory through the use of huge pages +which is a mechanism supported by modern architectures to optimise memory management. The algorithm begins by +allocating a fixed block of 1 GB physically contiguous memory. This decision is driven by the +architectural constraints of contemporary systems, particularly ARM-based CPUs. Where 1 GB represents the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated -with page table management and enhances memory access efficiency, which is critical for performance-sensitive +with page table management and enhances memory access. which is critical for performance-sensitive applications and kernel-level operations. \section{Evaluation} \label{sec:Evaluation} -We conducted tests of the FAT memory allocator against Jemalloc~\cite{jemalloc}, -Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}, to assess the performance improvements -enabled by the FAT allocator. Specifically, we evaluated +We conducted tests of the FAT memory allocator against Jemalloc~\cite{jemalloc}. +Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}. We evaluated the reduction in TLB walks and misses and its impact on wall clock runtime. To comprehensively analyse the proposed allocator, we categorised benchmarks into two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller -C programs designed to target specific allocator patterns, enabling us to evaluate -detailed aspects of the allocator's behavior. Macro benchmarks, on the other hand, -encompass larger, real-world C programs, allowing us to assess the allocator's -performance in more practical, real-world scenarios. +C programs designed to target specific allocator patterns which enables us to evaluate +detailed aspects of the allocators behavior. Macro benchmarks, on the other hand, +encompass larger real-world C programs allowing us to assess the allocators +performance in a more practical and real-world scenarios. % The experiment setup (section~\ref{sec:Experiment}) details the software stack used for evaluation. It includes % the specific configurations, compiler options, and system environment tailored @@ -789,7 +787,7 @@ performance in more practical, real-world scenarios. The CHERI Morello~\cite{Morello} board was used to evaluate the proposed memory allocator. Morello implements the ARM A76 with enhanced server-class memory, featuring a quad-core ARM CPU with capability extensions. The L1 and L2 caches were modified -to proliferate the capability bit, ensuring compatibility with CHERI's capability-based +to proliferate the capability bit which ensures compatibility with CHERI's capability-based memory model. When compiling the C programs for benchmarking, the Benchmark ABI was used as recommended by the CHERI community. This compilation mode was enabled using the Clang compiler. @@ -798,19 +796,19 @@ The Benchmark ABI~\cite{BenchmarkABI} was specifically designed because the More was not expanded to predict bounds. Consequently, a capability-based jump introduces stalls in later PCC-dependent instructions until bounds are established. This issue is particularly significant during dynamically linked calls and returns between -libraries, where bounds are changed to cover the called or returned-to library. +libraries where bounds are changed to cover the called or returned-to library. Such stalls can negatively affect performance, making the Benchmark ABI an essential consideration for this evaluation. Each C program was executed using two different memory allocators. The first was -the modified C allocator, imported as a header file. This approach was necessary -because the Benchmark ABI shared object file exhibited unexpected behavior, +the modified C allocator which is imported as a header file. This approach was necessary +because the Benchmark ABI shared object file exhibited unexpected behavior by failing to overwrite the C program at runtime with the intended \textit{malloc} functions. -The second allocator was the standard OS memory allocator, which, in the case of -CHERIBSD, is Jemalloc. +The second allocator was the standard OS memory allocator, which in the case of +CHERIBSD is Jemalloc. Performance measurements were carried out using ARM performance counters~\cite{PerformanceCounter} to -ensure accurate evaluation. These counters provided detailed metrics, allowing +ensure accurate evaluation. These counters provided detailed metrics allowing us to compare the performance of the two allocators and assess the impact of the proposed changes. @@ -857,28 +855,26 @@ the proposed changes. \end{table*} \subsection{Benchmarks} -The benchmarks~\cite{Benchmark} are classified into 2 classes: +We elaborate here on the two classes of benchmarks~\cite{Benchmark}. Micro benchmarks (Section~\ref{sec:Micro}). +focused on particular allocation and deallocation patterns such as sequential and +random memory accesses. This is to stress-test the allocator under controlled conditions. +Macro benchmarks involves real-world applications offering insights into how +the allocator performs with complex memory allocation demands such as large datasets with varying execution contexts. \subsubsection{Micro benchmark} -We further elaborated on the two classes of benchmarks executed. Micro benchmarks (Section~\ref{sec:Micro}). -focused on particular allocation and deallocation patterns, such as sequential and -random memory accesses, to stress-test the allocator under controlled conditions. -Macro benchmarks involved real-world applications, offering insights into how -the allocator performs with complex memory allocation demands, large datasets, -and varying execution contexts. \label{sec:Micro} \begin{itemize} \item \texttt{GLIBC}: The Glibc benchmark evaluates the performance of \textit{malloc} and \textit{free} functions in single-threaded, multi-threaded, - and emulated multi-threading scenarios using various block sizes and + and emulated multi-threading scenarios using various block sizes allocation patterns. It simulates real-world memory usage by partially deallocating blocks in FIFO order and fully deallocating them in LIFO order. Results are gathered across configurations to analyse performance variations. - \item \texttt{MemAccess}: This benchmark by Alex Bordei evaluates the performance impact of + \item \texttt{MemAccess}: This benchmark evaluates the performance impact of memory access patterns by constructing and traversing a doubly linked list with varying working set sizes. It supports sequential or - randomised structures, optional node operations, and multithreaded + randomised structures with optional node operations and multithreaded traversal using pthreads. The program dynamically allocates memory and systematically doubles the working set size to analyse memory hierarchy behavior. \end{itemize} @@ -888,18 +884,18 @@ and varying execution contexts. \begin{itemize} \item \texttt{Kmeans}: Kmeans implements a parallelised K-means clustering algorithm that -assigns data points to clusters based on proximity to centroids, -iteratively updating them until convergence. The computation is +assigns data points to clusters based on proximity to the centroids. +This iteratively updates them until convergence. The computation is distributed across threads using the pthread library, dynamically assigning tasks to optimise performance. Parameters like data size -and clusters are configurable, and the program ensures efficient +and clusters are configurable and the program ensures efficient memory management and synchronisation. \item \texttt{Richards}: Richards is a task scheduling benchmark that simulates a -multitasking environment with tasks of varying types and priorities, -communicating through queued packets. The schedule function manages -task execution based on state and priority, tracking processed packets -and held tasks for performance evaluation. Configurable iterations and -timing help measure system performance and ensure correctness. +multitasking environment with tasks of varying types and priorities which is +communicated through queued packets. The schedule function manages +task execution based on the state, priority and tracks processed packets +which are held tasks for performance evaluation. Configurable iterations and +timing help measure system performance to ensure correctness. \item \texttt{BARNES}: Implements the Barnes-Hut algorithm to efficiently simulate the interactions within an \(N\)-body system. A comprehensive overview of the Barnes-Hut method is provided by Singh in his doctoral dissertation ~\cite{singh1993}. The implementation we benchmark extends the original method by permitting multiple @@ -917,8 +913,8 @@ This extension is described by Holt and Singh ~\cite{holt1995}. \end{figure*} The graph (Figure \ref{fig:bargraph}) highlights the performance comparison between the modified memory allocator and -Jemalloc, the default memory allocator. The FAT memory allocator, specifically optimised -for use with huge pages, demonstrates a clear advantage in scenarios where memory allocation +Jemalloc, the default memory allocator. The FAT memory allocator is specifically optimised +for use with huge pages and demonstrates a clear advantage in scenarios where memory allocation patterns benefit from its design. The results align with expectations, showcasing the impact of its capability to handle memory more efficiently by leveraging huge pages. @@ -940,23 +936,23 @@ of its capability to handle memory more efficiently by leveraging huge pages. \end{itemize} A particularly striking observation is the significant reduction in data TLB walks, -L2 data TLB reads, and TLB refills-consistently show a 90\% decrease across all -benchmarks compared to Jemalloc. This improvement is due to the modified allocator's +L2 data TLB reads and TLB refills-consistently which show a 90\% decrease across all +benchmarks compared to Jemalloc. This improvement is due to the modified allocators use of a single huge page entry at the L1 TLB layer. By enabling most address translations to be resolved directly at the L1 TLB, the need to walk through the deeper TLB hierarchy is -largely eliminated. This reduction in translation overhead is a key factor in the allocator's +largely eliminated. This reduction in translation overhead is a key factor in the allocators performance for certain types of workloads. -The microbenchmarks, which are crafted to emphasize memory read operations, highlight the -allocator's strengths. These tests simulate frequent and intensive memory access patterns, +The microbenchmarks which are crafted to emphasise memory read operations, highlight the +allocators strengths. These tests simulate frequent and intensive memory access patterns, where the reduction in TLB misses directly translate into measurable performance gains. On average, the FAT allocator achieves a 50\% reduction in wall clock runtimes for -these workloads, underscoring its ability to optimise high-throughput memory operations. +these workloads. Underscoring its ability to optimise high-throughput memory operations. -On the other hand, macro benchmarks, which represent larger and more complex real-world applications , +On the other hand, macro benchmarks which represent larger and more complex real-world applications, exhibit minimal differences in wall clock runtimes when using the FAT allocator. This outcome is expected, as macro benchmarks typically involve a broader range of operations -beyond memory allocation, diluting the impact of the allocator's optimisations. Additionally, +beyond memory allocation. Additionally, the benefits of huge pages may be less pronounced for these workloads, as they are often bottlenecked by factors such as computation or I/O rather than memory translation overhead. @@ -968,22 +964,22 @@ bottlenecked by factors such as computation or I/O rather than memory translatio The K-means algorithm was executed with varying cluster sizes to evaluate the performance difference between the FAT allocator and Jemalloc as the workload scales. This analysis - aims to understand how the allocator's optimisations, particularly its ability to manage memory + aims to understand how the allocators optimisations, particularly its ability to manage memory more efficiently with huge pages, impact performance under different workload conditions. For most cluster sizes tested, the percentage difference in performance remained relatively -consistent. This indicates that the allocator's efficiency scales predictably with increasing -workload sizes, suggesting a stable and uniform benefit across different configurations. The -consistent performance gain is likely due to the allocator's ability to minimise TLB misses +consistent. This indicates that the allocators efficiency scales predictably with increasing +workload sizes. Suggesting a stable and uniform benefit across different configurations. The +consistent performance gain is likely due to the allocators ability to minimise TLB misses and efficiently manage memory allocations for the centroid and data point structures used in the K-means algorithm. However, an anomaly was observed at a cluster size of 2000, where the percentage difference deviated significantly from the trend. At this cluster size, the memory access patterns and allocation behavior may align in a way that temporarily offsets the advantages of the FAT allocator. For example, the memory layout -might interact with system-level caching mechanisms or TLB behavior differently, leading to an +might interact with system-level caching mechanisms or TLB behavior differently leading to an unexpected change in performance. Additionally, the increased complexity of managing a higher -number of clusters might introduce computational overhead that overshadows the memory allocator's +number of clusters might introduce computational overhead that overshadows the memory allocators optimisations. % This observation highlights the importance of testing across a range of workload sizes and @@ -1000,15 +996,15 @@ The FAT memory allocator demonstrates significant potential for enhancing memory management in systems that benefit from huge page optimisations. Its design effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads, and TLB refills compared to Jemalloc. These improvements lead to noticeable performance -gains, especially in micro benchmarks, where the allocator reduces wall clock runtimes +gains especially in micro benchmarks, where the allocator reduces wall clock runtimes by an average of 50\%. The allocator integrates seamlessly into memory-intensive workloads, as evidenced by its -consistent performance across varying cluster sizes in the K-means benchmark, with only +consistent performance across varying cluster sizes in the K-means benchmark with only minor anomalies observed under specific conditions. These outliers provide valuable -insights into the allocator's interaction with system-level caching and memory translation mechanisms. +insights into the allocators interaction with system-level caching and memory translation mechanisms. -While the allocator excels in scenarios emphasizing high-memory throughput, its impact on +While the allocator excels in scenarios emphasising on high-memory throughput. Its impact on macro benchmarks is less pronounced. This suggests that its benefits are most relevant for applications with frequent and intensive memory operations rather than those constrained by computation or I/O bottlenecks. @@ -1048,7 +1044,7 @@ to minimise fragmentation. \newline The benchmarks demonstrate that the allocator reduces TLB misses by up to 90\%, leading to substantial performance gains in memory-intensive workloads, though the improvements are less pronounced -for larger, computation-heavy applications. These results highlight the allocator's potential to advance memory management +for larger and computation-heavy applications. These results highlight the allocators potential to advance memory management by repurposing CHERI's capability-based model with the use of huge pages. diff --git a/docs/EuroSys/Paper/track.txt b/docs/EuroSys/Paper/track.txt new file mode 100644 index 0000000..aa83b6e --- /dev/null +++ b/docs/EuroSys/Paper/track.txt @@ -0,0 +1 @@ +RMM