diff --git a/docs/EuroSys/Paper/jemalloc.org b/docs/EuroSys/Paper/jemalloc.org new file mode 100644 index 0000000..57ef4c9 --- /dev/null +++ b/docs/EuroSys/Paper/jemalloc.org @@ -0,0 +1,99 @@ +* Malloc +The provided pseudocode outlines a modified implementation +of jemalloc’s memory mapping routines, adapted to work with +a custom malloc(sz) allocator. Instead of relying on traditional +operating system mechanisms like mmap, the memory allocation is +handled using MALLOC(size) +-> refer pseudo code implementation. + +which refers to a simplified allocator +defined earlier. This custom allocator manages a preallocated +memory region, aligns the requested size, decrements a memory +counter, and returns a pointer with enforced bounds for memory +safety. This approach is especially suited for constrained or +security-focused environments such as CHERI, where strict +control over memory access and deterministic allocation +behavior is essential. + +The os_pages_map function 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 +is disallowed and returns NULL. + +If memory overcommitment +is allowed it forces the commit flag to true. +It then allocates memory using the custom MALLOC(size) function and validates +whether the returned pointer matches the requested address +(if one was provided). If there’s a mismatch, it unmaps (i.e calling FREE() -> ref algorithm) the +memory and returns NULL; otherwise, it returns the allocated +pointer. + +The pages_map function is a simplified variant that ignores +alignment and address constraints. It directly allocates the +requested memory size using the internal allocator and returns +the result. This is appropriate in scenarios where alignment is +either managed elsewhere or not critical. + +This approach mentioned above is embeded inside jemallocs strategy of managing memory through arenas and size classes. +In jemalloc, memory is divided into chunks, which are further subdivided into runs and regions to +handle allocations of various sizes efficiently. By aligning sizes and managing allocations within +predefined structures, jemalloc minimizes fragmentation (source: http://hydra.azilian.net/Papers/jemalloc.pdf) + +Not needed: +The pages_commit_impl function emulates memory commitment, a +feature in systems that support lazy memory allocation. It +reallocates memory using MALLOC(size) and checks whether +the returned pointer matches the expected address. If not, +it unmaps the memory and signals failure by returning true; +otherwise, it indicates success by returning false. + +Not needed: +Collectively, these routines demonstrate how jemalloc can be +adapted to operate atop a custom memory allocator instead of +relying on the OS. This enables jemalloc to function in +specialized environments that require stricter memory controls, +such as embedded systems or capability-based architectures, +while still maintaining its structure and allocation policies. + +* Free +The os_pages_unmap algorithm represents a customized abstraction of jemallocs +memory unmapping routine, designed to integrate with the previously defined simplified +free(ptr) implementation. In conventional jemalloc configurations, os_pages_unmap would +invoke low-level system calls such as munmap to release virtual memory pages back to the +operating system. However, in this adapted version, the function instead delegates the +deallocation to a higher-level FREE(addr) -> Point to algorithm implementation + +Not needed: +routine, which encapsulates memory management +within a user-defined allocator, rather than relying on direct interaction with the +operating system. + +The function begins by enforcing two invariants through assertions: first, that the input +address addr is aligned to the operating system's page size (os_page), and second, that +the size of the memory region is also a multiple of os_page. These alignment checks are +critical for maintaining consistency with jemalloc’s internal page-based memory +management semantics and ensuring compatibility with the allocator's expectations. + +Following these checks, the memory at the specified address is deallocated via the +FREE(addr) operation. As previously defined in the free(ptr) pseudocode, this involves +retrieving the size of the allocated region through bounds metadata +(reference section) and invoking an internal unmap routine to mark the region +as available. + +The following changes done to free is embedded inside jemallocs 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 +separate metadata structures to track allocations, allowing for quick deallocation and reuse of memory blocks +without significant overhead. + +Not needed: +This design enables jemalloc to operate seamlessly in environments where +standard system-level memory operations are either restricted or abstracted away, such +as in sandboxed, embedded, or capability-based systems like CHERI. + + +Not needed: +Overall, this approach demonstrates how jemalloc’s modular architecture can be extended +to support alternative memory management strategies. By redirecting low-level memory +operations to custom allocators, developers can adapt jemalloc to function effectively +in constrained or security-critical execution contexts, without compromising on its +underlying allocation model or safety guarantees. diff --git a/docs/EuroSys/Paper/jemalloc.org~ b/docs/EuroSys/Paper/jemalloc.org~ new file mode 100644 index 0000000..04b8488 --- /dev/null +++ b/docs/EuroSys/Paper/jemalloc.org~ @@ -0,0 +1,43 @@ +The provided pseudocode outlines a modified implementation +of jemalloc’s memory mapping routines, adapted to work with +a custom malloc(sz) allocator. Instead of relying on traditional +operating system mechanisms like mmap, the memory allocation is +handled using MALLOC(size), which refers to a simplified allocator +defined earlier. This custom allocator manages a preallocated +memory region, aligns the requested size, decrements a memory +counter, and returns a pointer with enforced bounds for memory +safety. This approach is especially suited for constrained or +security-focused environments such as CHERI, where strict +control over memory access and deterministic allocation +behavior is essential. + +The os_pages_map function simulates jemalloc’s low-level page +mapping routine. It first checks if a specific address is +requested—a case relevant to CheriABI where such behavior +is disallowed—and returns NULL if so. If memory overcommitment +is allowed, it forces the commit flag to true. It then allocates +memory using the custom MALLOC(size) function and validates +whether the returned pointer matches the requested address +(if one was provided). If there’s a mismatch, it unmaps the +memory and returns NULL; otherwise, it returns the allocated +pointer. + +The pages_map function is a simplified variant that ignores +alignment and address constraints. It directly allocates the +requested memory size using the internal allocator and returns +the result. This is appropriate in scenarios where alignment is +either managed elsewhere or not critical. + +The pages_commit_impl function emulates memory commitment, a +feature in systems that support lazy memory allocation. It +reallocates memory using MALLOC(size) and checks whether +the returned pointer matches the expected address. If not, +it unmaps the memory and signals failure by returning true; +otherwise, it indicates success by returning false. + +Collectively, these routines demonstrate how jemalloc can be +adapted to operate atop a custom memory allocator instead of +relying on the OS. This enables jemalloc to function in +specialized environments that require stricter memory controls, +such as embedded systems or capability-based architectures, +while still maintaining its structure and allocation policies. diff --git a/docs/EuroSys/Paper/paper.aux b/docs/EuroSys/Paper/paper.aux index 178dfc5..efdcf0e 100644 --- a/docs/EuroSys/Paper/paper.aux +++ b/docs/EuroSys/Paper/paper.aux @@ -41,12 +41,10 @@ \@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 } +\@writefile{toc}{\contentsline {section}{\numberline {5}Memory allocator design}{3}{section.5}\protected@file@percent } +\newlabel{sec:MemoryAllocator}{{5}{3}{Memory allocator design}{section.5}{}} \citation{jemalloc} \citation{cheribsd} -\citation{Benchmark} -\citation{Morello} -\@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}{}} \@writefile{loa}{\contentsline {algorithm}{\numberline {1}{\ignorespaces Malloc implementation}}{4}{algorithm.1}\protected@file@percent } \newlabel{alg:malloc}{{1}{4}{Malloc implementation}{algorithm.1}{}} \@writefile{loa}{\contentsline {algorithm}{\numberline {2}{\ignorespaces Free implementation}}{4}{algorithm.2}\protected@file@percent } @@ -54,14 +52,18 @@ \@writefile{loa}{\contentsline {algorithm}{\numberline {3}{\ignorespaces Init alloc function to create a initial 1 GB huge page}}{4}{algorithm.3}\protected@file@percent } \newlabel{alg:initAlloc}{{3}{4}{Init alloc function to create a initial 1 GB huge page}{algorithm.3}{}} \@writefile{toc}{\contentsline {section}{\numberline {6}Embedding FAT allocator inside Jemalloc}{4}{section.6}\protected@file@percent } -\@writefile{toc}{\contentsline {section}{\numberline {7}Evaluation}{4}{section.7}\protected@file@percent } -\newlabel{sec:Evaluation}{{7}{4}{Evaluation}{section.7}{}} +\@writefile{loa}{\contentsline {algorithm}{\numberline {4}{\ignorespaces Modified Jemalloc Memory Mapping Routines}}{4}{algorithm.4}\protected@file@percent } +\newlabel{alg:JemallocMalloc}{{4}{4}{Modified Jemalloc Memory Mapping Routines}{algorithm.4}{}} +\citation{Benchmark} +\citation{Morello} \citation{BenchmarkABI} \citation{PerformanceCounter} -\@writefile{loa}{\contentsline {algorithm}{\numberline {4}{\ignorespaces Modified Jemalloc Memory Mapping Routines}}{5}{algorithm.4}\protected@file@percent } -\newlabel{alg:JemallocMalloc}{{4}{5}{Modified Jemalloc Memory Mapping Routines}{algorithm.4}{}} +\citation{singh1993} +\citation{holt1995} \newlabel{alg:JemallocFree}{{\caption@xref {alg:JemallocFree}{ on input line 827}}{5}{Embedding FAT allocator inside Jemalloc}{algorithm.4}{}} \@writefile{loa}{\contentsline {algorithm}{\numberline {5}{\ignorespaces os\_pages\_unmap}}{5}{algorithm.5}\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 } \newlabel{sec:Experiment}{{7.1}{5}{Experiment setup}{subsection.7.1}{}} \@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Benchmarks}{5}{subsection.7.2}\protected@file@percent } @@ -69,10 +71,8 @@ \@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.1}Micro benchmark}{5}{subsubsection.7.2.1}\protected@file@percent } \newlabel{sec:Macro}{{7.2.2}{5}{Macro benchmark}{subsubsection.7.2.2}{}} \@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.2}Macro benchmark}{5}{subsubsection.7.2.2}\protected@file@percent } -\citation{singh1993} -\citation{holt1995} -\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results}{6}{subsection.7.3}\protected@file@percent } -\newlabel{sec:Results}{{7.3}{6}{Results}{subsection.7.3}{}} +\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results}{5}{subsection.7.3}\protected@file@percent } +\newlabel{sec:Results}{{7.3}{5}{Results}{subsection.7.3}{}} \@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces ARM performance counters}}{6}{table.caption.4}\protected@file@percent } \newlabel{tab:org246a883}{{1}{6}{ARM performance counters}{table.caption.4}{}} \newlabel{table:ARMPerf}{{1}{6}{ARM performance counters}{table.caption.4}{}} @@ -90,8 +90,6 @@ \newlabel{sub@fig:wallclock}{{f}{7}{Wall Clock Time}{figure.caption.5}{}} \@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Benchmarks comparing the percentage difference between FAT.}}{7}{figure.caption.5}\protected@file@percent } \newlabel{fig:benchmarks-group}{{2}{7}{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}}} @@ -106,6 +104,10 @@ \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}}} +\@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}{}} +\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusion}{8}{section.8}\protected@file@percent } +\@writefile{toc}{\contentsline {section}{References}{8}{section*.7}\protected@file@percent } \bibcite{jemalloc}{{13}{2006}{{Evans}}{{}}} \bibcite{cheribsd}{{14}{}{{che}}{{}}} \bibcite{Benchmark}{{15}{}{{Ben}}{{}}} @@ -121,8 +123,6 @@ \newlabel{tocindent3}{18.198pt} \newlabel{tocindent4}{0pt} \newlabel{tocindent5}{0pt} -\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusion}{9}{section.8}\protected@file@percent } -\@writefile{toc}{\contentsline {section}{References}{9}{section*.7}\protected@file@percent } \newlabel{TotPages}{{9}{9}{}{page.9}{}} \gdef\svg@ink@ver@settings{{\m@ne }{inkscape}{\m@ne }} \gdef \@abspage@last{9} diff --git a/docs/EuroSys/Paper/paper.fdb_latexmk b/docs/EuroSys/Paper/paper.fdb_latexmk index e9b9b50..b86f574 100644 --- a/docs/EuroSys/Paper/paper.fdb_latexmk +++ b/docs/EuroSys/Paper/paper.fdb_latexmk @@ -1,13 +1,13 @@ # Fdb version 4 -["bibtex paper"] 1748298354.94538 "paper.aux" "paper.bbl" "paper" 1748298357.47654 0 +["bibtex paper"] 1748542391.49982 "paper.aux" "paper.bbl" "paper" 1748542393.50586 0 "./paperReferences.bib" 1746971882.78313 50975 d23cf0e29e30a59879e0a43f7bd63014 "" "/usr/local/texlive/2025/texmf-dist/bibtex/bst/natbib/unsrtnat.bst" 1233624470 24550 a41a6405f4de768c43e871d9fbce2bc8 "" - "paper.aux" 1748298357.087 9430 ccff33579246ecce72fa55d0a77e6d17 "pdflatex" + "paper.aux" 1748542393.18687 9430 f2d638c91d61664cb189252cfa34b0aa "pdflatex" (generated) "paper.bbl" "paper.blg" (rewritten before read) -["pdflatex"] 1748298355.05037 "paper.tex" "paper.pdf" "paper" 1748298357.47672 0 +["pdflatex"] 1748542391.64154 "paper.tex" "paper.pdf" "paper" 1748542393.506 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 "" @@ -254,10 +254,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_png.png" 1748297803.36134 22858 0c9dbeaa2b2a2c8d4588aeb499d141da "" - "paper.aux" 1748298357.087 9430 ccff33579246ecce72fa55d0a77e6d17 "pdflatex" - "paper.bbl" 1748298355.0467 8420 47d3ab73b727b7165b20d774bb45ad1a "bibtex paper" - "paper.out" 1748298357.08809 3482 dfb5cd2e0b64721769d9bbb90a3777d7 "pdflatex" - "paper.tex" 1748298348.19746 97986 3d168af49491944c70254477c1890880 "" + "paper.aux" 1748542393.18687 9430 f2d638c91d61664cb189252cfa34b0aa "pdflatex" + "paper.bbl" 1748542391.63845 8420 47d3ab73b727b7165b20d774bb45ad1a "bibtex paper" + "paper.out" 1748542393.18782 3482 dfb5cd2e0b64721769d9bbb90a3777d7 "pdflatex" + "paper.tex" 1748537227.43593 98923 e8aacff771f33802f685e767cf224fa6 "" (generated) "paper.aux" "paper.log" diff --git a/docs/EuroSys/Paper/paper.fls b/docs/EuroSys/Paper/paper.fls index ae6644e..e8e0843 100644 --- a/docs/EuroSys/Paper/paper.fls +++ b/docs/EuroSys/Paper/paper.fls @@ -559,11 +559,11 @@ INPUT ./diagram/drawing_png.png INPUT ./diagram/drawing_png.png INPUT ./diagram/drawing_png.png INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1.tfm -INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineTI-tlf-t1.vf -INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1--base.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-sc-t1.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-t1.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-t1.tfm +INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineTI-tlf-t1.vf +INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1--base.tfm INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd @@ -578,44 +578,44 @@ INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/stxscr.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineT-tlf-ot1.vf INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-ot1--base.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_oexx6f.enc -INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/newtx/nxlmia.vf INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/LibertineMathRM.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/txmiaSTbb.tfm INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/txmiaX.tfm +INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1.tfm +INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png +INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png +INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png +INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png +INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png +INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png +INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png +INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png +INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png +INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png +INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png +INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png +INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png +INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png +INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png +INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png +INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinBiolinumTI-tlf-t1.vf INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1--base.tfm -INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png -INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png -INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png -INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png -INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png -INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png -INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png -INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png -INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png -INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png -INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png -INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png -INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png -INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png -INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png -INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png -INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png INPUT ./paper.bbl INPUT ./paper.bbl INPUT paper.bbl diff --git a/docs/EuroSys/Paper/paper.log b/docs/EuroSys/Paper/paper.log index 45fd650..5f36b83 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) 26 MAY 2025 23:25 +This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 29 MAY 2025 19:13 entering extended mode \write18 enabled. %&-line parsing enabled. @@ -1509,20 +1509,6 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be (Font) scaled to size 9.0pt on input line 534. - -LaTeX Warning: Reference `fig:RangeOfMemory' on page 3 undefined on input line -571. - - -LaTeX Warning: Reference `fig:HugePages' on page 3 undefined on input line 665. - - - -Underfull \vbox (badness 10000) has occurred while \output is active [] - - - -[3.3 <./diagram/drawing_png.png>] Package hyperref Info: bookmark level for unknown algorithm defaults to 0 on in put line 689. LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/sc' will be @@ -1533,6 +1519,8 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be (Font) scaled to size 5.5pt on input line 693. +[3.3 <./diagram/drawing_png.png>] + LaTeX Font Info: Trying to load font information for T1+zi4 on input line 77 7. (/usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd @@ -1569,15 +1557,15 @@ ory al-lo-ca-tor for CHERIBSD [[]]. [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}] +c}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc}] + +Underfull \vbox (badness 5681) has occurred while \output is active [] + + LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/it' will be (Font) scaled to size 9.0pt on input line 963. - - -[5.5{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc -}] - File: diagram/benchmarks-group/bargraph-large-dtlb-walk.png Graphic file (type png) @@ -1585,7 +1573,7 @@ png) Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-dtlb-walk.png used on input line 1050. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - File: diagram/benchmarks-group/bargraph-large-l1tlb-reads.png Graphic file (typ e png) @@ -1593,7 +1581,7 @@ e png) Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-reads.pn g used on input line 1055. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - File: diagram/benchmarks-group/bargraph-large-l1tlb-refill.png Graphic file (ty pe png) @@ -1601,7 +1589,7 @@ pe png) Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-refill.p ng used on input line 1063. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - File: diagram/benchmarks-group/bargraph-large-l2tlb-reads.png Graphic file (typ e png) @@ -1609,7 +1597,7 @@ e png) Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l2tlb-reads.pn g used on input line 1068. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - File: diagram/benchmarks-group/bargraph-large-ll-cache-rd.png Graphic file (typ e png) @@ -1617,7 +1605,7 @@ e png) Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-ll-cache-rd.pn g used on input line 1076. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - File: diagram/benchmarks-group/bargraph-large-wallclock.png Graphic file (type png) @@ -1626,13 +1614,11 @@ Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-wallclock.png used on input line 1081. (pdftex.def) Requested size: 241.14749pt x 137.79964pt. - Class acmart Warning: A possible image without description on input line 1089. -Underfull \vbox (badness 10000) has occurred while \output is active [] - +[5.5] Underfull \vbox (badness 10000) has occurred while \output is active [] @@ -1645,12 +1631,6 @@ Underfull \vbox (badness 10000) has occurred while \output is active [] -Overfull \hbox (1.64574pt too wide) in paragraph at lines 1126--1134 -[]\T1/LinuxLibertineT-TLF/m/n/9 (-20) DTLB walks: Data Trans-la-tion Looka-side - Buffer (dTLB) walks, - [] - - Underfull \vbox (badness 10000) has occurred while \output is active [] @@ -1660,15 +1640,13 @@ marks-group/bargraph-large-l1tlb-reads.png> <./diagram/benchmarks-group/bargrap h-large-l1tlb-refill.png> <./diagram/benchmarks-group/bargraph-large-l2tlb-read s.png> <./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png> <./diagram/b enchmarks-group/bargraph-large-wallclock.png>] - - Underfull \vbox (badness 10000) has occurred while \output is active [] -[8.8] (./paper.bbl - +(./paper.bbl +[8.8] Underfull \hbox (badness 2443) in paragraph at lines 141--145 []\T1/LinuxLibertineT-TLF/m/n/7 (+20) CHERI-allocator/benchmarks/benchmarks/Str essTestMalloc/glibc-bench.c at @@ -1687,8 +1665,10 @@ Class acmart Warning: CCS concepts are mandatory for papers over two pages. -Package balance Warning: You have called \balance in second column -(balance) Columns might not be balanced. + + +Overfull \vbox (1.152pt too high) has occurred while \output is active [] + (/usr/local/texlive/2025/texmf-dist/tex/generic/stringenc/se-pdfdoc.def File: se-pdfdoc.def 2019/11/29 v1.12 stringenc: PDFDocEncoding @@ -1709,13 +1689,13 @@ Package rerunfilecheck Info: File `paper.out' has not changed. (rerunfilecheck) Checksum: DFB5CD2E0B64721769D9BBB90A3777D7;3482. ) Here is how much of TeX's memory you used: - 26504 strings out of 473190 - 451278 string characters out of 5715801 - 1049088 words of memory out of 5000000 - 48526 multiletter control sequences out of 15000+600000 - 779187 words of font info for 476 fonts, out of 8000000 for 9000 + 26499 strings out of 473190 + 451169 string characters out of 5715801 + 1043466 words of memory out of 5000000 + 48524 multiletter control sequences out of 15000+600000 + 778914 words of font info for 474 fonts, out of 8000000 for 9000 1302 hyphenation exceptions out of 8191 - 94i,17n,131p,1002b,780s stack positions out of 10000i,1000n,20000p,200000b,200000s + 94i,17n,131p,1002b,797s stack positions out of 10000i,1000n,20000p,200000b,200000s -Output written on paper.pdf (9 pages, 824270 bytes). +Output written on paper.pdf (9 pages, 820640 bytes). PDF statistics: 339 PDF objects out of 1000 (max. 8388607) 283 compressed objects within 3 object streams diff --git a/docs/EuroSys/Paper/paper.pdf b/docs/EuroSys/Paper/paper.pdf index 3f929a4..8edb610 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 80a4066..7a6eea3 100644 --- a/docs/EuroSys/Paper/paper.tex +++ b/docs/EuroSys/Paper/paper.tex @@ -568,12 +568,12 @@ FAT memory ranges are established using bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019}. % as referred in section ~\ref{sec:128bitCompressedBounds}. -Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single -large contiguous memory area or huge page. Within this huge page the orange and blue lines indicate -two separate memory allocations equivalent to invoking \textit{malloc} twice to allocate memory in distinct regions. -This scenario simulates a block-based memory allocator operating within the confines of a huge page. -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. +% 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 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. \section{128 bit compressed bounds} \label{sec:128bitCompressedBounds} @@ -662,12 +662,12 @@ memory patterns within physically contiguous memory. %Overall, it simplifies memory operations while improving performance %and reduces TLB overhead by reducing TLB walks. -Figure \ref{fig:HugePages} illustrates a use-case of huge pages where the green -line represents sample access to read within a contiguous -space of physical memory. The dotted lines represent the -bounds for that particular pointer access. Using bounds -stored on the pointer a block-based pattern can be replicated -on physically contiguous memory. +% Figure \ref{fig:HugePages} illustrates a use-case of huge pages where the green +% line represents sample access to read within a contiguous +% space of physical memory. The dotted lines represent the +% bounds for that particular pointer access. Using bounds +% stored on the pointer a block-based pattern can be replicated +% on physically contiguous memory. \section{Memory allocator design} \label{sec:MemoryAllocator} @@ -1104,28 +1104,37 @@ patterns benefit from its design. The results align with expectations, showcasin of its capability to handle memory more efficiently by leveraging huge pages. \begin{itemize} - \item L1 DTLB reads: L1 Data TLB reads are critical for achieving fast memory access, and a reduction - in events that could signify misses or lead to further lookups is generally beneficial. FAT allocator consistently performed - at the baseline level (100\%) across all benchmarks including Kmeans, Memaccess, Glibc, Richards, and Barnes. - In contrast, FAT allocator embedded inside Jemalloc exhibited varied performance. It achieved a notable 14\% - reduction in L1D TLB reads for Kmeans and a minor 3\% reduction for Barnes. More significantly, it - led to a substantial 68\% reduction for Memaccess, a benchmark characterized by linked list traversals - that can challenge memory access efficiency, and a 59\% reduction for Glibc, which involves numerous memory - allocation and deallocation operations. For the Richards benchmark, however, no significant change was observed with - 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 Data TLB reads are critical for achieving fast memory access, and a reduction + % in events that could signify misses or lead to further lookups is generally beneficial. FAT allocator consistently performed + % at the baseline level (100\%) across all benchmarks including Kmeans, Memaccess, Glibc, Richards, and Barnes. + % In contrast, FAT allocator embedded inside Jemalloc exhibited varied performance. It achieved a notable 14\% + % reduction in L1D TLB reads for Kmeans and a minor 3\% reduction for Barnes. More significantly, it + % led to a substantial 68\% reduction for Memaccess, a benchmark characterized by linked list traversals + % that can challenge memory access efficiency, and a 59\% reduction for Glibc, which involves numerous memory + % allocation and deallocation operations. For the Richards benchmark, however, no significant change was observed with + % 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 + 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. \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. + 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 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 benchmark with FAT allocator embedded inside Jemalloc. - \item DTLB walks: Data Translation Lookaside Buffer (dTLB) walks, which occur when a virtual-to-physical + \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 + 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. 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 @@ -1137,30 +1146,31 @@ of its capability to handle memory more efficiently by leveraging huge pages. 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 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. + refills would typically be expected. + % 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 (LLC) 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 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. - FAT allocator embedded inside Jemalloc showed a 75\% reduction in misses for Memaccess, a substantial improvement. Conversely, it led to an 18\% increase in - misses for Kmeans, a massive 375\% increase for Glibc, and a 65\% increase for Barnes. For the Richards benchmark, its performance was at the baseline. - 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 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. 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. + % FAT allocator embedded inside Jemalloc showed a 75\% reduction in misses for Memaccess, a substantial improvement. Conversely, it led to an 18\% increase in + % misses for Kmeans, a massive 375\% increase for Glibc, and a 65\% increase for Barnes. For the Richards benchmark, its performance was at the baseline. + % 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. - 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 - translate into an overall speedup. It was about 1\% slower on Richards. - FAT allocator embedded inside Jemalloc was 4\% faster for Memaccess, aligning well with its significant LL cache miss reduction and L1D TLB improvements - for that benchmark. It performed at baseline for Kmeans and was negligibly faster (0.5\%) for Richards. However, it was 15\% slower for Glibc, a slowdown - consistent with the massive increase in LL cache misses observed. For Barnes, it resulted in an 8\% slowdown, which also correlates with its increased - LL cache misses for that benchmark. These wallclock results underscore that improvements in a single specific memory subsystem metric do not always guarantee - an overall application speedup, as the interplay of various factors determines the final performance. + % \item Wall clock: Wallclock time provides the ultimate measure of overall execution performance, 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 + % translate into an overall speedup. It was about 1\% slower on Richards. + % FAT allocator embedded inside Jemalloc was 4\% faster for Memaccess, aligning well with its significant LL cache miss reduction and L1D TLB improvements + % for that benchmark. It performed at baseline for Kmeans and was negligibly faster (0.5\%) for Richards. However, it was 15\% slower for Glibc, a slowdown + % consistent with the massive increase in LL cache misses observed. For Barnes, it resulted in an 8\% slowdown, which also correlates with its increased + % LL cache misses for that benchmark. These wallclock results underscore that improvements in a single specific memory subsystem metric do not always guarantee + % an overall application speedup, as the interplay of various factors determines the final performance. \end{itemize} A particularly striking observation is the significant reduction in data TLB walks,