fixing grammer mistakes

This commit is contained in:
2025-04-20 15:32:53 +01:00
parent 35afa3f1ac
commit 8fda50a0f1
9 changed files with 174 additions and 157 deletions

View File

@@ -82,19 +82,20 @@
\bibcite{panwar_hawkeye_2019}{{2}{}{{}}{{}}}
\bibcite{woodruff_cheri_2014}{{3}{}{{}}{{}}}
\bibcite{woodruff_cheri_2019}{{4}{}{{}}{{}}}
\bibcite{THP}{{5}{}{{}}{{}}}
\bibcite{Shadow_superpages}{{6}{}{{}}{{}}}
\bibcite{DirectSegment}{{7}{}{{}}{{}}}
\bibcite{karakostas_redundant_2015}{{8}{}{{}}{{}}}
\bibcite{chen_flexpointer_2023}{{9}{}{{}}{{}}}
\bibcite{jemalloc}{{10}{}{{}}{{}}}
\bibcite{cheribsd}{{11}{}{{}}{{}}}
\bibcite{Morello}{{12}{}{{}}{{}}}
\bibcite{BenchmarkABI}{{13}{}{{}}{{}}}
\bibcite{PerformanceCounter}{{14}{}{{}}{{}}}
\bibcite{Benchmark}{{15}{}{{}}{{}}}
\bibcite{singh1993}{{16}{}{{}}{{}}}
\bibcite{holt1995}{{17}{}{{}}{{}}}
\bibcite{TLBReach}{{5}{}{{}}{{}}}
\bibcite{THP}{{6}{}{{}}{{}}}
\bibcite{Shadow_superpages}{{7}{}{{}}{{}}}
\bibcite{DirectSegment}{{8}{}{{}}{{}}}
\bibcite{karakostas_redundant_2015}{{9}{}{{}}{{}}}
\bibcite{chen_flexpointer_2023}{{10}{}{{}}{{}}}
\bibcite{jemalloc}{{11}{}{{}}{{}}}
\bibcite{cheribsd}{{12}{}{{}}{{}}}
\bibcite{Morello}{{13}{}{{}}{{}}}
\bibcite{BenchmarkABI}{{14}{}{{}}{{}}}
\bibcite{PerformanceCounter}{{15}{}{{}}{{}}}
\bibcite{Benchmark}{{16}{}{{}}{{}}}
\bibcite{singh1993}{{17}{}{{}}{{}}}
\bibcite{holt1995}{{18}{}{{}}{{}}}
\newlabel{tocindent-1}{0pt}
\newlabel{tocindent0}{0pt}
\newlabel{tocindent1}{4.185pt}

View File

@@ -28,6 +28,12 @@ Jonathan Woodruff, Alexandre Joannou, Hongyan Xia, Anthony Fox, Robert~M.
\newblock {CHERI} concentrate: Practical compressed capabilities.
\newblock 68(10):1455--1469.
\bibitem{TLBReach}
Binh Pham, Abhishek Bhattacharjee, Yasuko Eckert, and Gabriel~H. Loh.
\newblock Increasing tlb reach by exploiting clustering in page translations.
\newblock In {\em 2014 IEEE 20th International Symposium on High Performance
Computer Architecture (HPCA)}, pages 558--567, 2014.
\bibitem{THP}
Juan Navarro.
\newblock Practical, transparent operating system support for superpages.

View File

@@ -4,16 +4,15 @@ The top-level auxiliary file: paper.aux
The style file: unsrt.bst
Database file #1: paperReferences.bib
Warning--entry type for "cheribsd" isn't style-file defined
--line 471 of file paperReferences.bib
--line 483 of file paperReferences.bib
Warning--entry type for "jemalloc" isn't style-file defined
--line 493 of file paperReferences.bib
--line 505 of file paperReferences.bib
Warning--entry type for "Benchmark" isn't style-file defined
--line 500 of file paperReferences.bib
--line 512 of file paperReferences.bib
Warning--entry type for "Morello" isn't style-file defined
--line 507 of file paperReferences.bib
--line 519 of file paperReferences.bib
Warning--entry type for "PerformanceCounter" isn't style-file defined
--line 514 of file paperReferences.bib
Warning--I didn't find a database entry for "TLBReach"
--line 526 of file paperReferences.bib
Warning--empty journal in mittal_survey_2017
Warning--empty year in mittal_survey_2017
Warning--empty year in panwar_hawkeye_2019
@@ -26,45 +25,45 @@ Warning--empty year in THP
Warning--empty year in karakostas_redundant_2015
Warning--empty journal in chen_flexpointer_2023
Warning--empty year in chen_flexpointer_2023
You've used 17 entries,
You've used 18 entries,
1791 wiz_defined-function locations,
535 strings with 6867 characters,
and the built_in function-call counts, 3698 in all, are:
= -- 273
> -- 215
< -- 3
+ -- 80
- -- 63
* -- 278
:= -- 567
add.period$ -- 44
call.type$ -- 17
change.case$ -- 16
540 strings with 7108 characters,
and the built_in function-call counts, 4072 in all, are:
= -- 306
> -- 229
< -- 4
+ -- 85
- -- 67
* -- 299
:= -- 615
add.period$ -- 47
call.type$ -- 18
change.case$ -- 17
chr.to.int$ -- 0
cite$ -- 29
duplicate$ -- 153
empty$ -- 369
format.name$ -- 63
if$ -- 806
cite$ -- 30
duplicate$ -- 174
empty$ -- 407
format.name$ -- 67
if$ -- 900
int.to.chr$ -- 0
int.to.str$ -- 17
missing$ -- 10
newline$ -- 79
num.names$ -- 12
pop$ -- 74
int.to.str$ -- 18
missing$ -- 11
newline$ -- 84
num.names$ -- 13
pop$ -- 80
preamble$ -- 1
purify$ -- 0
quote$ -- 0
skip$ -- 95
skip$ -- 111
stack$ -- 0
substring$ -- 191
swap$ -- 31
text.length$ -- 3
substring$ -- 219
swap$ -- 42
text.length$ -- 4
text.prefix$ -- 0
top$ -- 0
type$ -- 0
warning$ -- 12
while$ -- 27
width$ -- 19
write$ -- 151
(There were 18 warnings)
while$ -- 30
width$ -- 20
write$ -- 162
(There were 17 warnings)

View File

@@ -1,13 +1,13 @@
# Fdb version 4
["bibtex paper"] 1744986008.45602 "paper.aux" "paper.bbl" "paper" 1744986010.05022 0
"./paperReferences.bib" 1744390239.54673 46323 d7b94a445857170fc1233321d0322eaa ""
["bibtex paper"] 1745154910.17453 "paper.aux" "paper.bbl" "paper" 1745154911.75342 0
"./paperReferences.bib" 1745154876.64218 46828 b3c7e70331098da6a7fbd68e2a4277a3 ""
"/usr/local/texlive/2025/texmf-dist/bibtex/bst/base/unsrt.bst" 1292289607 18030 1376b4b231b50c66211e47e42eda2875 ""
"paper.aux" 1744986009.74502 7732 6c392b230f302222e5e050064e5cc1a4 "pdflatex"
"paper.aux" 1745154911.45033 7767 2d2fd3c4d1929deee7aebd01524eab86 "pdflatex"
(generated)
"paper.bbl"
"paper.blg"
(rewritten before read)
["pdflatex"] 1744986008.53877 "paper.tex" "paper.pdf" "paper" 1744986010.05034 0
["pdflatex"] 1745154910.25767 "paper.tex" "paper.pdf" "paper" 1745154911.75354 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" 1744986009.74502 7732 6c392b230f302222e5e050064e5cc1a4 "pdflatex"
"paper.bbl" 1744986008.53583 3824 3a7d4db0e425f84ef7bb98164f0eac8f "bibtex paper"
"paper.out" 1744986009.7459 3243 8666c5d883f1c403037236be395fbf0f "pdflatex"
"paper.tex" 1744985983.05866 84406 580da4eab7518a9734e3d6b079523aa0 ""
"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 ""
(generated)
"paper.aux"
"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) 18 APR 2025 15:20
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
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
@@ -1207,10 +1207,6 @@ 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.
Package natbib Warning: Citation `TLBReach' on page 1 undefined on input line 3
88.
Underfull \vbox (badness 4913) has occurred while \output is active []
@@ -1277,7 +1273,7 @@ ocal/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_naooyc.enc}
{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_nh77jq.enc}{
/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_7grukw.enc}]
<diagram/HighOverviewArchitecture.drawio.png, id=124, 1072.005pt x 836.12375pt>
<diagram/HighOverviewArchitecture.drawio.png, id=126, 1072.005pt x 836.12375pt>
File: diagram/HighOverviewArchitecture.drawio.png Graphic file (type png)
<use diagram/HighOverviewArchitecture.drawio.png>
@@ -1299,7 +1295,7 @@ LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/n' will be
(Font) scaled to size 7.0pt on input line 526.
[2.2]
<diagram/AllocationOverview24.png, id=139, 723.70375pt x 501.875pt>
<diagram/AllocationOverview24.png, id=141, 723.70375pt x 501.875pt>
File: diagram/AllocationOverview24.png Graphic file (type png)
<use diagram/AllocationOverview24.png>
Package pdftex.def Info: diagram/AllocationOverview24.png used on input line 5
@@ -1311,7 +1307,7 @@ Class acmart Warning: A possible image without description on input line 546.
<diagram/TLBAccess.drawio.png, id=144, 773.89125pt x 945.5325pt>
<diagram/TLBAccess.drawio.png, id=146, 773.89125pt x 945.5325pt>
File: diagram/TLBAccess.drawio.png Graphic file (type png)
<use diagram/TLBAccess.drawio.png>
Package pdftex.def Info: diagram/TLBAccess.drawio.png used on input line 619.
@@ -1361,7 +1357,7 @@ Package microtype Info: Loading generic protrusion settings for font family
(microtype) `zi4' (encoding: T1).
(microtype) For optimal results, create family-specific settings.
(microtype) See the microtype manual for details.
<diagram/bargraph.png, id=180, 1156.32pt x 722.7pt>
<diagram/bargraph.png, id=182, 1156.32pt x 722.7pt>
File: diagram/bargraph.png Graphic file (type png)
<use diagram/bargraph.png>
Package pdftex.def Info: diagram/bargraph.png used on input line 917.
@@ -1388,7 +1384,7 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
[6.6]
<./diagram/kmeans.png, id=205, 1011.78pt x 578.16pt>
<./diagram/kmeans.png, id=207, 1011.78pt x 578.16pt>
File: ./diagram/kmeans.png Graphic file (type png)
<use ./diagram/kmeans.png>
Package pdftex.def Info: ./diagram/kmeans.png used on input line 967.
@@ -1404,29 +1400,26 @@ Class acmart Warning: A possible image without description on input line 969.
Overfull \hbox (1.21416pt too wide) in paragraph at lines 1001--1007
\T1/LinuxLibertineT-TLF/m/n/9 (-20) page op-ti-miza-tions. Its de-sign ef-fec-t
ively re-duces TLB misses, achiev-
[]
Underfull \vbox (badness 10000) has occurred while \output is active []
[7.7 <./diagram/bargraph.png> <./diagram/kmeans.png>] (./paper.bbl
[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
Underfull \hbox (badness 2443) in paragraph at lines 85--87
Underfull \hbox (badness 2443) in paragraph at lines 91--93
[]\T1/LinuxLibertineT-TLF/m/n/7 (+20) CHERI-allocator/benchmarks/benchmarks/Str
essTestMalloc/glibc-bench.c at
[]
)
Package natbib Warning: There were undefined citations.
Class acmart Warning: Some images may lack descriptions.
@@ -1456,11 +1449,11 @@ Package rerunfilecheck Info: File `paper.out' has not changed.
(rerunfilecheck) Checksum: 8666C5D883F1C403037236BE395FBF0F;3243.
)
Here is how much of TeX's memory you used:
24043 strings out of 473190
394342 string characters out of 5715801
967318 words of memory out of 5000000
46198 multiletter control sequences out of 15000+600000
776437 words of font info for 457 fonts, out of 8000000 for 9000
24052 strings out of 473190
394523 string characters out of 5715801
967612 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
1302 hyphenation exceptions out of 8191
90i,17n,131p,1002b,645s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/local/texlive/2025/texmf-dist/fonts/type1/public/inconsolata/Inconsolat
@@ -1474,10 +1467,10 @@ lic/libertine/LinLibertineTB.pfb></usr/local/texlive/2025/texmf-dist/fonts/type
1/public/libertine/LinLibertineTI.pfb></usr/local/texlive/2025/texmf-dist/fonts
/type1/public/newtx/NewTXMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1
/public/newtx/txsys.pfb>
Output written on paper.pdf (8 pages, 710137 bytes).
Output written on paper.pdf (8 pages, 710830 bytes).
PDF statistics:
291 PDF objects out of 1000 (max. 8388607)
242 compressed objects within 3 object streams
59 named destinations out of 1000 (max. 500000)
293 PDF objects out of 1000 (max. 8388607)
244 compressed objects within 3 object streams
60 named destinations out of 1000 (max. 500000)
119498 words of extra memory for PDF output out of 128383 (max. 10000000)

Binary file not shown.

View File

@@ -327,20 +327,20 @@
% accelerating memory management operations.
In computing, achieving high performance is an ongoing challenge, especially as
applications handle increasingly complex workloads. Memory management is a key factor
in performance, where efficient use of resources is essential. Translation Lookaside
Buffers (TLBs) are crucial in this context, speeding up memory access by caching recent
memory address translations. A TLB, a specialised cache in the memory management unit (MMU),
reduces the time required to convert virtual addresses to physical ones. When a program accesses
data in memory, the MMU first checks the TLB for a matching entry, avoiding the slower process of
consulting page tables. However, as applications grow more complex, the fixed size of
applications handle increasingly memory intensive workloads. Memory management is a key factor
in reducing the time it takes to access a memory region. Translation Lookaside Buffers (TLBs)
are crucial in speeding up memory access by caching recent
memory address translations. A 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. However, as applications grow more complex, the fixed size of
TLBs often cannot keep up, leading to more TLB misses and performance slowdowns~\cite{mittal_survey_2017}.
To tackle this issue, researchers have explored new solutions, including the use of
huge pages~\cite{panwar_hawkeye_2019}.
Huge pages, also known as large pages, allow for the allocation of memory in significantly larger chunks
compared to traditional small pages. By reducing the number of TLB entries needed to access a given amount
of memory, huge pages offer a potential avenue for optimising TLBs are used by reducing the number
of memory, huge pages offer a potential avenue for optimising TLBs which are used by reducing the number
of entries needed to map large memory regions. This not only decreases the frequency of
TLB misses but also lowers the overhead associated with address translation. By minimising
these bottlenecks, huge pages can improve system performance in aspects such as speeding
@@ -350,17 +350,17 @@ workloads that rely heavily on large datasets.
Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
~\cite{woodruff_cheri_2014} architecture presents additional opportunities for performance enhancement. CHERI's capability-based addressing approach not
only strengthens system security by tightly controlling memory access but also opens avenues for optimising memory management
operations. By integrating CHERIs compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, We have shown it is possible to track and manage
large, physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces TLB pressure by minimising the number of
operations. By integrating CHERI's compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, We have shown it is possible to track and manage
large, physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces the TLB pressure by minimising the number of
entries required to map extensive memory regions, thereby decreasing TLB misses and improving address translation performance.
Furthermore, it accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
Furthermore, we introduce FAT which accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
memory allocations. The contributions for the following paper are as follows:
\begin{itemize}
\item \textbf{FAT Addresses Translations}: Introduces FAT that include memory bounds, allowing
efficient tracking and management of physically contiguous memory regions (Section ~\ref{sec:FatPointerTranslations}).
\item \textbf{CHERIs Capability-based Optimization}: Demonstrates how CHERI's architecture can be
used to optimize memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
\item \textbf{CHERIs Capability-based Optimisation}: Demonstrates how CHERI's architecture can be
used to optimise memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
(Section ~\ref{sec:128bitCompressedBounds}).
\item \textbf{Memory Allocation Algorithms}: Provides an algorithms for allocating, freeing
@@ -368,10 +368,10 @@ 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 allocators ability
to reduce TLB misses by up to 90\%, yielding significant improvements in wall clock runtimes for memory-intensive
applications. While its impact on larger, computation-heavy workloads is less pronounced,
the proposed allocator shows strong potential for advancing memory management in scenarios requiring
Through comprehensive evaluation including micro and macro benchmarks, we demonstrate the allocator's 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
high memory throughput by reducing the address translation overhead.
\section{Related work}
@@ -385,26 +385,26 @@ high memory throughput by reducing the address translation overhead.
% and end of the segment. Any virtual address within this region
% can be translated by adding the fixed offset between the virtual
% and physical address.
Increasing TLB reach\cite{TLBReach} can be achieved by using larger page sizes, such as huge pages~\cite{panwar_hawkeye_2019}, which are common in modern computer systems.
The x86-64 architecture supports huge pages of 2 MB and 1 GB, backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
and HugeTLBFS in Linux. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues.
Increasing TLB reach\cite{TLBReach} can be achieved by using larger page sizes such as huge pages~\cite{panwar_hawkeye_2019} which are common in modern computer systems.
The x86-64 architecture supports huge pages of 2 MB and 1 GB which are backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues.
% Alternate segment technique
% - JayneelGandhi,ArkapravaBasu,MarkD.Hill,andMichaelM.Swift.2014.Efficientmemoryvirtualization:Reducing
For instance, allocating 1 MB with 4 KB base pages requires 256 PTEs (Page Table Entries), but using a 2 MB huge page would waste
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium, which
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organize huge
pages, but without significant changes to the conventional page table, it only helps reduce page walk overheads.
Huge page tunable base page size permits the OS to adjust the base page, but still faces internal fragmentation problems,
For instance, allocating 1 MB with 4 KB base pages requires 256 PTEs (Page Table Entries) and in contrast using a 2 MB huge page would waste
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium which
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organise huge
pages and without significant changes to the conventional page table. It only helps reduce page walk overheads.
Huge page tunable base page size permits the OS to adjust the base page, but still faces internal fragmentation problems
with huge page recommending a base page size of no more than 16 KB. Shadow Superpage~\cite{Shadow_superpages} introduces a new translation level
in the memory controller to merge non-contiguous physical pages into a huge page in a shadow memory space, extending
TLB coverage. However, this approach requires all memory traffic to be translated again in the memory controller,
in the memory controller to merge non-contiguous physical pages into a huge page in a shadow memory space by extending
TLB coverage. However, this approach requires all memory traffic to be translated again in the memory controller
resulting in additional latency for memory accesses.
\subsection{Direct Segment}
Early processors often used segments to manage virtual memory, where a segment~\cite{DirectSegment} essentially mapped contiguous
virtual memory to contiguous physical memory. Unlike pages, which are relatively small, segments can be much
larger, offering the potential for more efficient memory management in certain scenarios.
virtual memory to contiguous physical memory. Unlike pages which are relatively small, segments can be much
larger offering the potential for more efficient memory management.
This concept of segmentation has seen a resurgence in some modern approaches that aim to enhance
translation coverage by designating specific areas in the virtual address space.
@@ -419,22 +419,20 @@ source code of applications.
\subsection{Redundant Memory Mapping (RMM)}
Redundant Memory Mappings (RMM)~\cite{karakostas_redundant_2015} enhance memory management by introducing an additional range table
that pre-allocates contiguous physical pages for large memory allocations, creating ranges that
that pre-allocates contiguous physical pages for large memory allocations thus creating ranges that
are both virtually and physically contiguous. This approach simplifies address translation
within these ranges by adding an offset, similar to Direct Segment, but RMM supports multiple
ranges and operates transparently to programmers, requiring no source code modifications.
The range table, separate from the conventional page table, holds the mappings for these
by adding ranges. RMM is similar to Direct Segment with the support of multiple
ranges and operates transparently to programmers. No source code modifications is required on the programmers
side. The range table which is separate from the conventional page table holds the mappings for these
large allocations. To determine which range an address belongs to, RMM compares the address
against all range boundaries, a process that is computationally expensive and therefore performed
only after an L1 TLB miss. To optimize this, RMM uses a range TLB (RTLB) to quickly identify
if an address falls within any pre-allocated range, facilitating efficient translation and
reducing overhead. Range mapping works alongside the paging system by generating TLB entries on
TLB misses and still performing TLB lookups for each virtual address translation.
Unlike traditional segmentation mechanisms, range mapping activates a range lookaside
buffer (RTLB) located with the last level TLB upon a miss. The hardware TLB miss
handler then searches the RTLB for the missed address and, if found, generates a new
against all range boundaries. Since this process is computationally expensive hence it is therefore performed
only after an L1 TLB miss. To optimise this, RMM uses a Range TLB (RTLB) to quickly identify
if an address falls within any pre-allocated range. Range mapping works alongside the paging system by generating TLB entries on
TLB misses and still performs TLB lookups for each virtual address translation.
Unlike traditional segmentation mechanisms, range mapping activates the RTLB located with the last level TLB upon a miss. The hardware TLB miss
handler then searches the RTLB for the missed address. If found, generates a new
TLB entry with the physical address derived from the base virtual address and
range offset, along with permission bits. If the RTLB also misses, the system
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
@@ -460,22 +458,22 @@ reducing the need for costly page table walks.
% \end{itemize}
CHERI extends conventional processor Instruction-Set Architectures (ISAs)
with architectural capabilities to enable fine-grained memory protection
and highly scalable software compartmentalization. It is a hybrid capability
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 compartmentalization; language and compiler extensions for using capabilities with C and C++; and OS extensions to
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
for scalable software compartmentalization.
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
capability pointers. Capability pointers enhance memory safety by embedding bounds and permissions directly
within pointers, but traditional implementations double their size—leading to increased memory usage. CHERI CC
proposes a compression strategy that preserves security while reducing size and inefficiencies. Key contributions include a floating-point
bound encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimized space usage for larger ones.
bound encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimised space usage for larger ones.
\section{Fat Address Translations}
\label{sec:FatPointerTranslations}
@@ -659,7 +657,7 @@ on physically contiguous memory.
\label{sec:MemoryAllocator}
This section presents a straightforward memory allocator designed and 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 initializes the memory pool, setting up the necessary
\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.
@@ -740,8 +738,8 @@ efficient memory management but also demonstrate a practical use case of huge pa
\end{algorithmic}
\end{algorithm}
Algorithm \ref{alg:initAlloc} describes the initialization of physically contiguous memory through the use of huge pages,
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
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
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
@@ -755,7 +753,7 @@ Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}, to assess
enabled by the FAT allocator. Specifically, we evaluated
the reduction in TLB walks and misses and its impact on wall clock runtime.
To comprehensively analyze the proposed allocator, we categorized benchmarks into
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,
@@ -876,26 +874,26 @@ and varying execution contexts.
and emulated multi-threading scenarios using various block sizes and
allocation patterns. It simulates real-world memory usage by partially
deallocating blocks in FIFO order and fully deallocating them in LIFO order.
Results are gathered across configurations to analyze performance variations.
Results are gathered across configurations to analyse performance variations.
\item \texttt{MemAccess}: This benchmark by Alex Bordei evaluates the performance impact of
memory access patterns by constructing and traversing a doubly
linked list with varying working set sizes. It supports sequential or
randomized structures, optional node operations, and multithreaded
randomised structures, optional node operations, and multithreaded
traversal using pthreads. The program dynamically allocates memory and systematically
doubles the working set size to analyze memory hierarchy behavior.
doubles the working set size to analyse memory hierarchy behavior.
\end{itemize}
\subsubsection{Macro benchmark}
\label{sec:Macro}
\begin{itemize}
\item \texttt{Kmeans}: Kmeans implements a parallelized K-means clustering algorithm that
\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
distributed across threads using the pthread library, dynamically
assigning tasks to optimize performance. Parameters like data size
assigning tasks to optimise performance. Parameters like data size
and clusters are configurable, and the program ensures efficient
memory management and synchronization.
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
@@ -919,7 +917,7 @@ 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 optimized
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
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.
@@ -953,12 +951,12 @@ The microbenchmarks, which are crafted to emphasize memory read operations, high
allocator's 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 optimize 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 ,
exhibit minimal differences in wall clock runtimes when using the FAT allocator.
This outcome is expected, as macro benchmarks typically involve a broader range of operations
beyond memory allocation, diluting the impact of the allocator's optimizations. Additionally,
beyond memory allocation, diluting the impact of the allocator's optimisations. 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.
@@ -970,13 +968,13 @@ 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 optimizations, particularly its ability to manage memory
aims to understand how the allocator's 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 minimize TLB misses
consistent performance gain is likely due to the allocator's ability to minimise TLB misses
and efficiently manage memory allocations for the centroid and data point structures used in
the K-means algorithm.
@@ -986,7 +984,7 @@ temporarily offsets the advantages of the FAT allocator. For example, the memory
might interact with system-level caching mechanisms or TLB behavior differently, leading to an
unexpected change in performance. Additionally, the increased complexity of managing a higher
number of clusters might introduce computational overhead that overshadows the memory allocator's
optimizations.
optimisations.
% This observation highlights the importance of testing across a range of workload sizes and
% configurations to uncover edge cases or specific scenarios where performance deviates from the
@@ -999,7 +997,7 @@ optimizations.
\label{sec:Analysis}
The FAT memory allocator demonstrates significant potential for enhancing
memory management in systems that benefit from huge page optimizations. Its design
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
@@ -1041,7 +1039,7 @@ This paper addresses the growing disparity between application workloads and the
To mitigate this gap, we proposed leveraging physically contiguous memory with CHERI bounds to reduce TLB walks.
We designed a memory allocator that uses huge pages with the CHERI CC scheme to track allocations within the
allocated huge page. This approach reduces the number of TLB entries needed while using bounds
to minimize fragmentation.
to minimise fragmentation.
% Additionally,
% the report explores advancements in system security, particularly through the Capability Hardware Enhanced RISC Instructions (CHERI)
% architecture. CHERI's capability-based addressing enhances system security by associating capabilities with memory pointers,

View File

@@ -21,6 +21,18 @@ abstract = {While superpages are an efficient solution to increase TLB reach, st
file = {Navarro - Practical, transparent operating system support fo.pdf:/Users/akilan/Zotero/storage/R9MSCWQX/Navarro - Practical, transparent operating system support fo.pdf:application/pdf},
}
@INPROCEEDINGS{TLBReach,
author={Pham, Binh and Bhattacharjee, Abhishek and Eckert, Yasuko and Loh, Gabriel H.},
booktitle={2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA)},
title={Increasing TLB reach by exploiting clustering in page translations},
year={2014},
volume={},
number={},
pages={558-567},
keywords={Virtual private networks;Hardware;Organizations;Benchmark testing;Prefetching;Operating systems},
doi={10.1109/HPCA.2014.6835964}
}
@article{DirectSegment,
author = {Basu, Arkaprava and Gandhi, Jayneel and Chang, Jichuan and Hill, Mark D. and Swift, Michael M.},
title = {Efficient virtual memory for big memory servers},

View File

@@ -1,12 +1,14 @@
- [ ] Captilisation fixes
- [ ] Check for unessary commas
- [ ] Check references
- [ ] Unify english grammer
Recheck require read of the paper
- [x] Captilisation fixes (Recheck)
- [ ] Check for unessary commas (Requires read through paper) (Recheck)
- [ ] Check references (Last priority)
- [x] Unify english grammer (emphasize -> Check british english spelling) (Recheck)
- [x] Text make to italics (For function calls)
- [x] Space missing from bracket
- [x] Utlizing to using
- [x] Small number use word
- [ ] Make all past tense to present tense
- [x] Make all past tense to present tense (Recheck)
- [x] Comment out future work section
- [x] Section with always captial S
- [x] RMM fix reference
@@ -56,3 +58,9 @@
** Conclusion
- [x] "This approach has helped reduce" -> "This approach reduces"
- [x] "Remove comprehensive"
** Read 1
*** Introduction
- [ ] Check if Rob mentioned paraphrasing setence 1.