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

added introduction section

Browse Source
This commit is contained in:
Akilan Selvacoumar
2025-01-20 13:34:14 +00:00
parent 486c190514
commit 36640a07fc
19 changed files with 1412 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.vscode/settings.json vendored
View File

@@ -55,7 +55,9 @@
"ratio": "cpp",
"tuple": "cpp",
"variant": "cpp",
"stddef.h": "c"
"stddef.h": "c",
"stdlib.h": "c",
"errno.h": "c"
},
"C_Cpp.errorSquiggles": "disabled"
}

194
KernelModule/customMemAlloc.c
View File

@@ -31,6 +31,27 @@ __FBSDID("$FreeBSD$");
#include <vm/vm_pager.h>
#include <vm/vm_phys.h>
#include <cheriintrin.h>
#include <cheri/cheric.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <assert.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/errno.h>
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
// added to print uint
// 64
// #include <inttypes.h>
@@ -78,6 +99,11 @@ static SYSCTL_NODE(_hw_contigmem, OID_AUTO, physaddr, CTLFLAG_RD, 0,
MALLOC_DEFINE(M_CONTIGMEM, "customcontigmem", "customcontigmem(4) allocations");
void *ptr;
int MallocCounter;
#define MAXPAGESIZES 2
/*
* The offset in sysent where the syscall is allocated.
@@ -120,79 +146,80 @@ static struct cdevsw contigmem_ops = {
.d_close = contigmem_close,
};
static int
pagesizes(size_t ps[MAXPAGESIZES])
{
int pscnt;
pscnt = getpagesizes(ps, MAXPAGESIZES);
// ATF_REQUIRE_MSG(pscnt != -1, "getpagesizes failed; errno=%d", errno);
// ATF_REQUIRE_MSG(ps[0] != 0, "psind 0 is %zu", ps[0]);
// ATF_REQUIRE_MSG(pscnt <= MAXPAGESIZES, "invalid pscnt %d", pscnt);
// if (pscnt == 1){
// printf("pscnt is 1");
// }
// atf_tc_skip("no large page support");
return (pscnt);
}
static int
contigmem_load()
{
// get page size
printf("%d FreeBSD page size \n",PAGE_SIZE);
size_t sz;
// Pre Allocate 1GB huge page
sz = 1073741824;
char index_string[8], description[32];
int i, error = 0;
void *addr;
int error, fd, pscnt, pn;
if (contigmem_num_buffers > RTE_CONTIGMEM_MAX_NUM_BUFS) {
printf("%d buffers requested is greater than %d allowed\n",
contigmem_num_buffers, RTE_CONTIGMEM_MAX_NUM_BUFS);
error = EINVAL;
goto error;
}
size_t ps[MAXPAGESIZES];
if (contigmem_buffer_size < PAGE_SIZE ||
(contigmem_buffer_size & (contigmem_buffer_size - 1)) != 0) {
printf("buffer size 0x%lx is not greater than PAGE_SIZE and "
"power of two\n", contigmem_buffer_size);
error = EINVAL;
goto error;
}
size_t size[3];
for (i = 0; i < contigmem_num_buffers; i++) {
addr = contigmalloc(contigmem_buffer_size, M_CONTIGMEM, M_ZERO,
0, BUS_SPACE_MAXADDR, contigmem_buffer_size, 0);
if (addr == NULL) {
printf("contigmalloc failed for buffer %d\n", i);
error = ENOMEM;
goto error;
}
pn = getpagesizes(size, 3);
printf("page size is [%d]", size[2]);
#ifndef RTE_ARCH_ARM_PURECAP_HACK
printf("%2u: virt=%p phys=%p\n", i, addr,
(void *)pmap_kextract((vm_offset_t)addr));
#endif
pscnt = pagesizes(ps);
mtx_init(&contigmem_buffers[i].mtx, "contigmem", NULL, MTX_DEF);
contigmem_buffers[i].addr = addr;
contigmem_buffers[i].refcnt = 0;
fd = shm_create_largepage(SHM_ANON, O_CREAT | O_RDWR, 1, SHM_LARGEPAGE_ALLOC_DEFAULT, 0);
snprintf(index_string, sizeof(index_string), "%d", i);
snprintf(description, sizeof(description),
"phys addr for buffer %d", i);
SYSCTL_ADD_PROC(NULL,
&SYSCTL_NODE_CHILDREN(_hw_contigmem, physaddr), OID_AUTO,
index_string, CTLTYPE_U64 | CTLFLAG_RD,
(void *)(uintptr_t)i, 0, contigmem_physaddr, "LU",
description);
}
if (fd < 0 && errno == ENOTTY) {
perror("sh_create_largepages");
close(fd);
}
// if (fd < 0)
// perror("no large page supported");
// exit(EXIT_FAILURE);
// if (fd < 0 && errno == ENOTTY)
// atf_tc_skip("no large page support");
// ATF_REQUIRE_MSG(fd >= 0, "shm_create_largepage failed; errno=%d", errno);
contigmem_cdev = make_dev_credf(0, &contigmem_ops, 0, NULL, UID_ROOT,
GID_WHEEL, 0600, "contigmem");
if (ftruncate(fd, sz) < 0) {
perror("ftruncate");
close(fd);
}
// if (error != 0 && errno == ENOMEM)
// /*
// * The test system might not have enough memory to accommodate
// * the request.
// */
// atf_tc_skip("failed to allocate %zu-byte superpage", sz);
// ATF_REQUIRE_MSG(error == 0, "ftruncate failed; errno=%d", errno);
ptr = mmap(NULL, sz,
PROT_READ|PROT_WRITE, MAP_SHARED,fd,0);
// Added error handling
if(ptr == MAP_FAILED)
{
perror("mmap");
exit(EXIT_FAILURE);
}
MallocCounter = (int)sz;
return 0;
error:
for (i = 0; i < contigmem_num_buffers; i++) {
if (contigmem_buffers[i].addr != NULL) {
contigfree(contigmem_buffers[i].addr,
contigmem_buffer_size, M_CONTIGMEM);
contigmem_buffers[i].addr = NULL;
}
if (mtx_initialized(&contigmem_buffers[i].mtx))
mtx_destroy(&contigmem_buffers[i].mtx);
}
return error;
// Want to design contig load to do nothing
}
static int
@@ -350,36 +377,45 @@ static struct cdev_pager_ops contigmem_cdev_pager_ops = {
};
static int
contigmem_mmap_single(struct cdev *cdev, vm_ooffset_t *offset, vm_size_t size,
(struct cdev *cdev, vm_ooffset_t *offset, vm_size_t size,
struct vm_object **obj, int nprot)
{
// Testing if this is called when file is opened
printf("contigmem_mmap_single called \n");
struct contigmem_vm_handle *vmh;
uint64_t buffer_index;
// struct contigmem_vm_handle *vmh;
// uint64_t buffer_index;
/*
* The buffer index is encoded in the offset. Divide the offset by
* PAGE_SIZE to get the index of the buffer requested by the user
* app.
*/
buffer_index = *offset / PAGE_SIZE;
if (buffer_index >= contigmem_num_buffers)
return EINVAL;
// /*
// * The buffer index is encoded in the offset. Divide the offset by
// * PAGE_SIZE to get the index of the buffer requested by the user
// * app.
// */
// buffer_index = *offset / PAGE_SIZE;
// if (buffer_index >= contigmem_num_buffers)
// return EINVAL;
if (size > contigmem_buffer_size)
return EINVAL;
// if (size > contigmem_buffer_size)
// return EINVAL;
vmh = malloc(sizeof(*vmh), M_CONTIGMEM, M_NOWAIT | M_ZERO);
if (vmh == NULL)
return ENOMEM;
vmh->buffer_index = buffer_index;
// vmh = malloc(sizeof(*vmh), M_CONTIGMEM, M_NOWAIT | M_ZERO);
// if (vmh == NULL)
// return ENOMEM;
// vmh->buffer_index = buffer_index;
*offset = (vm_ooffset_t)vtophys(contigmem_buffers[buffer_index].addr);
*obj = cdev_pager_allocate(vmh, OBJT_DEVICE, &contigmem_cdev_pager_ops,
size, nprot, *offset, curthread->td_ucred);
// *offset = (vm_ooffset_t)vtophys(contigmem_buffers[buffer_index].addr);
// *obj = cdev_pager_allocate(vmh, OBJT_DEVICE, &contigmem_cdev_pager_ops,
// size, nprot, *offset, curthread->td_ucred);
size = __builtin_align_up(size, _Alignof(max_align_t));
// printf("%d \n", sz);
// printf("%d Malloc counter\n", MallocCounter);
MallocCounter -= size;
obj = &ptr[MallocCounter];
obj = cheri_setbounds(obj, sz);
return 0;
}

1
README.md Normal file
View File

@@ -0,0 +1 @@
# CHERI Huge page memory allocator

BIN
docs/.DS_Store vendored Normal file
View File

Binary file not shown.

BIN
docs/evaluation/evaluation.pdf
View File

Binary file not shown.

24
docs/evaluation/evaluation.tex
View File

@@ -1,4 +1,4 @@
% Created 2025-01-16 Thu 15:20
% Created 2025-01-17 Fri 15:29
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
@@ -27,7 +27,7 @@
\tableofcontents
\section{Evaluation}
\label{sec:orgdc1fb32}
\label{sec:org3be955b}
We conducted tests of the FAT Pointer-based range addresses against Jemalloc\cite{jemalloc},
the default memory allocator for CHERIBSD\cite{cheribsd}, to assess the performance improvements
@@ -68,7 +68,7 @@ gains were marginal or where it introduced additional complexity in memory manag
limitations provide a roadmap for future optimizations and refinements of the allocator design.
\subsection{Expirement setup}
\label{sec:org1821dc1}
\label{sec:orgeb993d4}
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
@@ -99,7 +99,7 @@ us to compare the performance of the two allocators and assess the impact of
the proposed changes.
\begin{table}[htbp]
\caption{\label{tab:orgba41311}ARM performance counters}
\caption{\label{tab:org246a883}ARM performance counters}
\centering
\begin{tabular}{|l|l|}
\hline
@@ -141,12 +141,12 @@ Wall clock & The actual time taken from the start of a \\
\end{table}
\subsubsection{Benchmarks}
\label{sec:org76c5486}
\label{sec:orgf614dbb}
The benchmarks\cite{Benchmark} are classified into 2 classes:
\begin{enumerate}
\item Micro benchmark
\label{sec:org2f3b3d3}
\label{sec:org41c278c}
\begin{itemize}
\item GLIBC: The Glibc benchmark evaluates the performance of
malloc and free functions in single-threaded, multi-threaded,
@@ -163,7 +163,7 @@ doubles the working set size to analyze memory hierarchy behavior.
\end{itemize}
\item Macro runs
\label{sec:org1d39860}
\label{sec:org89020f2}
\begin{itemize}
\item Kmeans: Kmeans implements a parallelized K-means clustering algorithm that
assigns data points to clusters based on proximity to centroids,
@@ -182,15 +182,15 @@ timing help measure system performance and ensure correctness.
\end{enumerate}
\subsection{Results}
\label{sec:orgf4cf5db}
\label{sec:org921a6b3}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./diagrams/bargraph.png}
\caption{\label{fig:org876b3c0}Percentage difference between the modified memory allocator against the default system memory allocator}
\caption{\label{fig:orga7f3598}Percentage difference between the modified memory allocator against the default system memory allocator}
\end{figure}
The graph[\ref{fig:org876b3c0}] highlights the performance comparison between the modified memory allocator and
The graph[\ref{fig:orga7f3598}] highlights the performance comparison between the modified memory allocator and
Jemalloc, the default memory allocator. The FAT pointer memory allocator, specifically optimized
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
@@ -220,7 +220,7 @@ bottlenecked by factors such as computation or I/O rather than memory translatio
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{./diagrams/kmeans.png}
\caption{\label{fig:org5dab5a3}Kmeans COZ benchmark executed against various cluster sizes}
\caption{\label{fig:org8683315}Kmeans COZ benchmark executed against various cluster sizes}
\end{figure}
The K-means algorithm was executed with varying cluster sizes to evaluate the performance difference
@@ -251,7 +251,7 @@ behavior and guide future improvements to address such outliers. Despite the dev
cluster size of 2000, the overall results reaffirm the allocator's capability to maintain
consistent performance benefits across most scenarios.
\subsection{Usability}
\label{sec:orgb046e55}
\label{sec:orgd6ba6f0}
The FAT pointer memory allocator demonstrates significant potential for enhancing
memory management in systems that benefit from huge page optimizations. Its design
effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,

45
docs/introduction/intro-plan.org Normal file
View File

@@ -0,0 +1,45 @@
* Introduction plan
- First paragraph looks good to me.
- 2nd paragrah also looks fine.
- 3rd paragraph needs work
- [ ] Rewrite to mention
* Literature review plan
** Robs feedback
"In the dynamic landscape of computing, the pursuit of optimal performance is a constant endeavor" - this is far too wordy and
grandiose. Reviewers of scientific paper do no like phrases like "landscape of computing" or "constant endeavour". Also "utilization
of resources is paramount" - there are smaller words than "paramount", you should stick to small words.
I suggest you just stick a clear message in the introduction: (1) state the problem, (2) summarise existing approaches for this
problem (with citations), (3) summarise the limitations of those problems (with citations of papers that demonstrate those limitations),
(4) "We propose <NAME>, which <DESCRIBE>.", (5) "It overcomes these problems by <EXPLAIN>.". (6) "It performs <STATE RESULTS>.".
(7) "The contributions of this paper are...".
"leading to increased TLB misses and subsequent performance bottlenecks" - this would be better if you could quantify this
and cite a paper that reports this number. "E.g. 40% increased TLB misses resulting in 25% slowdowns [CITE]".
General comment: the "WHY?" you are doing this question is unclear from the introduction. And you need to get to the
"WHY?" question much earlier, i.e. there is too much verbose discussion huge pages and TLB and CHERI.
The *key* "WHY?" paraphrase you've written is:
"In this context, the integration of huge pages into memory management strategies alongside capability-based
addressing in architectures like CHERI offers a compelling synergy. By optimizing TLB utilization through the
utilization of huge pages and leveraging the security features of capability-based addressing, significant
performance improvements can be realized."
But there are several important problems with this paragraph:
1) It comes too late in the introduction, it should be stated much earlier.
2) Avoid wordy phrases like "compelling synergy" and long words like "leveraging".
3) "significant performance improvements can be realized" is far too non-committal! If the "WHY?" is "performance",
then this needs to be really (really) clear: state how existing huge pages + TLB approach suffer performance issues;
state why exactly your technique will outperform existing huge pages + TLB approaches; state what performance metric
you are referring to; state; then state that they "*are* realised" and give the performance numbers to back up this claim.

0
docs/introduction/introduction-plan.org Normal file
View File

59
docs/introduction/introduction.bbl Normal file
View File

@@ -0,0 +1,59 @@
% Generated by IEEEtran.bst, version: 1.14 (2015/08/26)
\begin{thebibliography}{1}
\providecommand{\url}[1]{#1}
\csname url@samestyle\endcsname
\providecommand{\newblock}{\relax}
\providecommand{\bibinfo}[2]{#2}
\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}
\providecommand{\BIBentryALTinterwordstretchfactor}{4}
\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus
\BIBentryALTinterwordstretchfactor\fontdimen3\font minus
\fontdimen4\font\relax}
\providecommand{\BIBforeignlanguage}[2]{{%
\expandafter\ifx\csname l@#1\endcsname\relax
\typeout{** WARNING: IEEEtran.bst: No hyphenation pattern has been}%
\typeout{** loaded for the language `#1'. Using the pattern for}%
\typeout{** the default language instead.}%
\else
\language=\csname l@#1\endcsname
\fi
#2}}
\providecommand{\BIBdecl}{\relax}
\BIBdecl
\bibitem{mittal_survey_2017}
\BIBentryALTinterwordspacing
S.~Mittal, ``A survey of techniques for architecting {TLBs},'' vol.~29, no.~10,
p. e4061, \_eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.4061.
[Online]. Available:
\url{https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.4061}
\BIBentrySTDinterwordspacing
\bibitem{panwar_hawkeye_2019}
\BIBentryALTinterwordspacing
A.~Panwar, S.~Bansal, and K.~Gopinath, ``{HawkEye}: Efficient fine-grained {OS}
support for huge pages,'' in \emph{Proceedings of the Twenty-Fourth
International Conference on Architectural Support for Programming Languages
and Operating Systems}.\hskip 1em plus 0.5em minus 0.4em\relax {ACM}, pp.
347--360. [Online]. Available:
\url{https://dl.acm.org/doi/10.1145/3297858.3304064}
\BIBentrySTDinterwordspacing
\bibitem{woodruff_cheri_2014}
\BIBentryALTinterwordspacing
J.~Woodruff, R.~N. Watson, D.~Chisnall, S.~W. Moore, J.~Anderson, B.~Davis,
B.~Laurie, P.~G. Neumann, R.~Norton, and M.~Roe, ``The {CHERI} capability
model: revisiting {RISC} in an age of risk,'' vol.~42, no.~3, pp. 457--468.
[Online]. Available: \url{https://doi.org/10.1145/2678373.2665740}
\BIBentrySTDinterwordspacing
\bibitem{woodruff_cheri_2019}
\BIBentryALTinterwordspacing
J.~Woodruff, A.~Joannou, H.~Xia, A.~Fox, R.~M. Norton, D.~Chisnall, B.~Davis,
K.~Gudka, N.~W. Filardo, A.~T. Markettos, M.~Roe, P.~G. Neumann, R.~N.~M.
Watson, and S.~W. Moore, ``{CHERI} concentrate: Practical compressed
capabilities,'' vol.~68, no.~10, pp. 1455--1469. [Online]. Available:
\url{https://ieeexplore.ieee.org/document/8703061/}
\BIBentrySTDinterwordspacing
\end{thebibliography}

426
docs/introduction/introduction.bib Normal file
View File

@@ -0,0 +1,426 @@
@article{navarro_practical_nodate,
title = {Practical, transparent operating system support for superpages},
abstract = {Most general-purpose processors provide support for memory pages of large sizes, called superpages. Superpages enable each entry in the translation lookaside buffer ({TLB}) to map a large physical memory region into a virtual address space. This dramatically increases {TLB} coverage, reduces {TLB} misses, and promises performance improvements for many applications. However, supporting superpages poses several challenges to the operating system, in terms of superpage allocation and promotion tradeoffs, fragmentation control, etc. We analyze these issues, and propose the design of an effective superpage management system. We implement it in {FreeBSD} on the Alpha {CPU}, and evaluate it on real workloads and benchmarks. We obtain substantial performance benefits, often exceeding 30\%; these benefits are sustained even under stressful workload scenarios.},
author = {Navarro, Juan},
langid = {english},
file = {Navarro - Practical, transparent operating system support fo.pdf:/Users/akilan/Zotero/storage/9RBYAPGM/Navarro - Practical, transparent operating system support fo.pdf:application/pdf},
}
@inproceedings{panwar_hawkeye_2019,
location = {Providence {RI} {USA}},
title = {{HawkEye}: Efficient Fine-grained {OS} Support for Huge Pages},
isbn = {978-1-4503-6240-5},
url = {https://dl.acm.org/doi/10.1145/3297858.3304064},
doi = {10.1145/3297858.3304064},
shorttitle = {{HawkEye}},
eventtitle = {{ASPLOS} '19: Architectural Support for Programming Languages and Operating Systems},
pages = {347--360},
booktitle = {Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems},
publisher = {{ACM}},
author = {Panwar, Ashish and Bansal, Sorav and Gopinath, K.},
urldate = {2024-05-27},
date = {2019-04-04},
langid = {english},
file = {Full Text PDF:/Users/akilan/Zotero/storage/VQLCKYCA/Panwar et al. - 2019 - HawkEye Efficient Fine-grained OS Support for Hug.pdf:application/pdf},
}
@inproceedings{karakostas_redundant_2015,
location = {Portland Oregon},
title = {Redundant memory mappings for fast access to large memories},
isbn = {978-1-4503-3402-0},
url = {https://dl.acm.org/doi/10.1145/2749469.2749471},
doi = {10.1145/2749469.2749471},
abstract = {Page-based virtual memory improves programmer productivity, security, and memory utilization, but incurs performance overheads due to costly page table walks after {TLB} misses. This overhead can reach 50\% for modern workloads that access increasingly vast memory with stagnating {TLB} sizes. To reduce the overhead of virtual memory, this paper proposes Redundant Memory Mappings ({RMM}), which leverage ranges of pages and provides an efficient, alternative representation of many virtual-to-physical mappings. We define a range be a subset of process’s pages that are virtually and physically contiguous. {RMM} translates each range with a single range table entry, enabling a modest number of entries to translate most of the process’s address space. {RMM} operates in parallel with standard paging and uses a software range table and hardware range {TLB} with arbitrarily large reach. We modify the operating system to automatically detect ranges and to increase their likelihood with eager page allocation. {RMM} is thus transparent to applications. We prototype {RMM} software in Linux and emulate the hardware. {RMM} performs substantially better than paging alone and huge pages, and improves a wider variety of workloads than direct segments (one range per program), reducing the overhead of virtual memory to less than 1\% on average.},
eventtitle = {{ISCA} '15: The 42nd Annual International Symposium on Computer Architecture},
pages = {66--78},
booktitle = {Proceedings of the 42nd Annual International Symposium on Computer Architecture},
publisher = {{ACM}},
author = {Karakostas, Vasileios and Gandhi, Jayneel and Ayar, Furkan and Cristal, Adrián and Hill, Mark D. and {McKinley}, Kathryn S. and Nemirovsky, Mario and Swift, Michael M. and Ünsal, Osman},
urldate = {2024-05-27},
date = {2015-06-13},
langid = {english},
file = {Karakostas et al. - 2015 - Redundant memory mappings for fast access to large.pdf:/Users/akilan/Zotero/storage/8JECES24/Karakostas et al. - 2015 - Redundant memory mappings for fast access to large.pdf:application/pdf},
}
@article{chen_flexpointer_2023,
title = {{FlexPointer}: Fast Address Translation Based on Range {TLB} and Tagged Pointers},
volume = {20},
issn = {1544-3566, 1544-3973},
url = {https://dl.acm.org/doi/10.1145/3579854},
doi = {10.1145/3579854},
shorttitle = {{FlexPointer}},
abstract = {Page-based virtual memory relies on {TLBs} to accelerate the address translation. Nowadays, the gap between application workloads and the capacity of {TLB} continues to grow, bringing many costly {TLB} misses and making the {TLB} a performance bottleneck. Previous studies seek to narrow the gap by exploiting the contiguity of physical pages. One promising solution is to group pages that are both virtually and physically contiguous into a memory range. Recording range translations can greatly increase the {TLB} reach, but ranges are also hard to index because they have arbitrary bounds. The processor has to compare against all the boundaries to determine which range an address falls in, which restricts the usage of memory ranges.
In this article, we propose a tagged-pointer-based scheme, {FlexPointer}, to solve the range indexing problem. The core insight of {FlexPointer} is that large memory objects are rare, so we can create memory ranges based on such objects and assign each of them a unique {ID}. With the range {ID} integrated into pointers, we can index the range {TLB} with {IDs} and greatly simplify its structure. Moreover, because the {ID} is stored in the unused bits of a pointer and is not manipulated by the address generation, we can shift the range lookup to an earlier stage, working in parallel with the address generation. According to our trace-based simulation results, {FlexPointer} can reduce nearly all the L1 {TLB} misses, and page walks for a variety of memory-intensive workloads. Compared with a 4K-page baseline system, {FlexPointer} shows a 14\% performance improvement on average and up to 2.8x speedup in the best case. For other workloads, {FlexPointer} shows no performance degradation.},
pages = {1--24},
number = {2},
journaltitle = {{ACM} Transactions on Architecture and Code Optimization},
shortjournal = {{ACM} Trans. Archit. Code Optim.},
author = {Chen, Dongwei and Tong, Dong and Yang, Chun and Yi, Jiangfang and Cheng, Xu},
urldate = {2024-05-27},
date = {2023-06-30},
langid = {english},
file = {Full Text PDF:/Users/akilan/Zotero/storage/L9XGZDFK/Chen et al. - 2023 - FlexPointer Fast Address Translation Based on Ran.pdf:application/pdf},
}
@article{woodruff_cheri_2019,
title = {{CHERI} Concentrate: Practical Compressed Capabilities},
volume = {68},
rights = {https://ieeexplore.ieee.org/Xplorehelp/downloads/license-information/{IEEE}.html},
issn = {0018-9340, 1557-9956, 2326-3814},
url = {https://ieeexplore.ieee.org/document/8703061/},
doi = {10.1109/TC.2019.2914037},
shorttitle = {{CHERI} Concentrate},
abstract = {We present {CHERI} Concentrate, a new fat-pointer compression scheme applied to {CHERI}, the most developed capability-pointer system at present. Capability fat pointers are a primary candidate to enforce fine-grained and non-bypassable security properties in future computer systems, although increased pointer size can severely affect performance. Thus, several proposals for capability compression have been suggested elsewhere that do not support legacy instruction sets, ignore features critical to the existing software base, and also introduce design inefficiencies to {RISC}-style processor pipelines. {CHERI} Concentrate improves on the state-of-the-art region-encoding efficiency, solves important pipeline problems, and eases semantic restrictions of compressed encoding, allowing it to protect a full legacy software stack. We present the first quantitative analysis of compiled capability code, which we use to guide the design of the encoding format. We analyze and extend logic from the open-source {CHERI} prototype processor design on {FPGA} to demonstrate encoding efficiency, minimize delay of pointer arithmetic, and eliminate additional load-to-use delay. To verify correctness of our proposed high-performance logic, we present a {HOL}4 machine-checked proof of the decode and pointer-modify operations. Finally, we measure a 50\% to 75\% reduction in L2 misses for many compiled C-language benchmarks running under a commodity operating system using compressed 128-bit and 64-bit formats, demonstrating both compatibility with and increased performance over the uncompressed, 256-bit format.},
pages = {1455--1469},
number = {10},
journaltitle = {{IEEE} Transactions on Computers},
shortjournal = {{IEEE} Trans. Comput.},
author = {Woodruff, Jonathan and Joannou, Alexandre and Xia, Hongyan and Fox, Anthony and Norton, Robert M. and Chisnall, David and Davis, Brooks and Gudka, Khilan and Filardo, Nathaniel W. and Markettos, A. Theodore and Roe, Michael and Neumann, Peter G. and Watson, Robert N. M. and Moore, Simon W.},
urldate = {2024-05-27},
date = {2019-10-01},
langid = {english},
file = {Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:/Users/akilan/Zotero/storage/3SZUIWQ5/Woodruff et al. - 2019 - CHERI Concentrate Practical Compressed Capabiliti.pdf:application/pdf},
}
@online{noauthor_capability-based_nodate,
title = {Capability-Based Computer Systems},
url = {https://homes.cs.washington.edu/~levy/capabook/},
urldate = {2024-06-07},
file = {Capability-Based Computer Systems:/Users/akilan/Zotero/storage/IAAG6ZF3/capabook.html:text/html},
}
@article{woodruff_cheri_2014,
title = {The {CHERI} capability model: revisiting {RISC} in an age of risk},
volume = {42},
issn = {0163-5964},
url = {https://doi.org/10.1145/2678373.2665740},
doi = {10.1145/2678373.2665740},
shorttitle = {The {CHERI} capability model},
abstract = {Motivated by contemporary security challenges, we reevaluate and refine capability-based addressing for the {RISC} era. We present {CHERI}, a hybrid capability model that extends the 64-bit {MIPS} {ISA} with byte-granularity memory protection. We demonstrate that {CHERI} enables language memory model enforcement and fault isolation in hardware rather than software, and that the {CHERI} mechanisms are easily adopted by existing programs for efficient in-program memory safety. In contrast to past capability models, {CHERI} complements, rather than replaces, the ubiquitous page-based protection mechanism, providing a migration path towards deconflating data-structure protection and {OS} memory management. Furthermore, {CHERI} adheres to a strict {RISC} philosophy: it maintains a load-store architecture and requires only singlecycle instructions, and supplies protection primitives to the compiler, language runtime, and operating system. We demonstrate a mature {FPGA} implementation that runs the {FreeBSD} operating system with a full range of software and an open-source application suite compiled with an extended {LLVM} to use {CHERI} memory protection. A limit study compares published memory safety mechanisms in terms of instruction count and memory overheads. The study illustrates that {CHERI} is performance-competitive even while providing assurance and greater flexibility with simpler hardware},
pages = {457--468},
number = {3},
journaltitle = {{ACM} {SIGARCH} Computer Architecture News},
shortjournal = {{SIGARCH} Comput. Archit. News},
author = {Woodruff, Jonathan and Watson, Robert N.M. and Chisnall, David and Moore, Simon W. and Anderson, Jonathan and Davis, Brooks and Laurie, Ben and Neumann, Peter G. and Norton, Robert and Roe, Michael},
urldate = {2024-06-07},
date = {2014-06-14},
}
@article{miller_towards_nodate,
title = {Towards a Unified Approach to Access Control and Concurrency Control},
author = {Miller, Mark Samuel},
langid = {english},
file = {Miller - Towards a Unified Approach to Access Control and Co.pdf:/Users/akilan/Zotero/storage/7METVAKG/Miller - Towards a Unified Approach to Access Control and Co.pdf:application/pdf},
}
@inproceedings{curtsinger_coz_2015,
title = {Coz: Finding Code that Counts with Causal Profiling},
url = {http://arxiv.org/abs/1608.03676},
doi = {10.1145/2815400.2815409},
shorttitle = {Coz},
abstract = {Improving performance is a central concern for software developers. To locate optimization opportunities, developers rely on software profilers. However, these profilers only report where programs spent their time: optimizing that code may have no impact on performance. Past profilers thus both waste developer time and make it difficult for them to uncover significant optimization opportunities.},
pages = {184--197},
booktitle = {Proceedings of the 25th Symposium on Operating Systems Principles},
author = {Curtsinger, Charlie and Berger, Emery D.},
urldate = {2024-06-07},
date = {2015-10-04},
langid = {english},
eprinttype = {arxiv},
eprint = {1608.03676 [cs]},
keywords = {C.4, Computer Science - Performance, D.4.8},
file = {Curtsinger and Berger - 2015 - Coz Finding Code that Counts with Causal Profilin.pdf:/Users/akilan/Zotero/storage/QTFQXVHE/Curtsinger and Berger - 2015 - Coz Finding Code that Counts with Causal Profilin.pdf:application/pdf},
}
@online{noauthor_benchmark_nodate,
title = {Benchmark {ABI} - {CheriBSD} 23.11 new features tutorial},
url = {https://www.cheribsd.org/tutorial/23.11/benchmark/index.html},
urldate = {2024-06-07},
file = {Benchmark ABI - CheriBSD 23.11 new features tutorial:/Users/akilan/Zotero/storage/9BDKUW28/index.html:text/html},
}
@inproceedings{zhu_research_2018,
location = {Taipei, Taiwan},
title = {Research and Implementation of High Performance Traffic Processing Based on Intel {DPDK}},
isbn = {978-1-5386-9403-9},
url = {https://ieeexplore.ieee.org/document/8701793/},
doi = {10.1109/PAAP.2018.00018},
eventtitle = {2018 9th International Symposium on Parallel Architectures, Algorithms and Programming ({PAAP})},
pages = {62--68},
booktitle = {2018 9th International Symposium on Parallel Architectures, Algorithms and Programming ({PAAP})},
publisher = {{IEEE}},
author = {Zhu, Wenjun and Li, Peng and Luo, Baozhou and Xu, He and Zhang, Yujie},
urldate = {2024-06-07},
date = {2018-12},
}
@article{bi_dpdk-based_2016,
title = {{DPDK}-based Improvement of Packet Forwarding},
volume = {7},
rights = {© Owned by the authors, published by {EDP} Sciences, 2016},
issn = {2271-2097},
url = {https://www.itm-conferences.org/articles/itmconf/abs/2016/02/itmconf_ita2016_01009/itmconf_ita2016_01009.html},
doi = {10.1051/itmconf/20160701009},
abstract = {Reel-time processing of packets occupies a significant position in the field of computer network security. With theexplosive growth of the backbone link rate,which is consistent with Gilder's law, many bottlenecks of server performance leave the real-time data stream unprocessed.Thus, we proposedto take use of {DPDK}(Data Plan Development Kit) framework to achieve an intelligent {NIC} packet forwarding system. During this research, we deeply analysis the forwarding process of packet in {DPDK} and improve its {DMA} mode.According to the results of experiment, the system greatly enhanced the performance of packet forwarding,and the throughput of forwarding 64-byet or random-length packets by 20Gbit {NIC} reaches13.3Gbps and 18.7Gbps(dual ports forwarding).},
pages = {01009},
journaltitle = {{ITM} Web of Conferences},
shortjournal = {{ITM} Web Conf.},
author = {Bi, Hao and Wang, Zhao-Hun},
urldate = {2024-06-07},
date = {2016},
langid = {english},
note = {Publisher: {EDP} Sciences},
file = {Full Text PDF:/Users/akilan/Zotero/storage/LEVMJ983/Bi and Wang - 2016 - DPDK-based Improvement of Packet Forwarding.pdf:application/pdf},
}
@article{esswood_cherios_nodate,
title = {{CheriOS}: designing an untrusted single-address-space capability operating system utilising capability hardware and a minimal hypervisor},
author = {Esswood, Lawrence G},
langid = {english},
file = {Esswood - CheriOS designing an untrusted single-address-spa.pdf:/Users/akilan/Zotero/storage/YGIBFTD5/Esswood - CheriOS designing an untrusted single-address-spa.pdf:application/pdf},
}
@book{wilkes_cambridge_1979,
location = {New York},
title = {The Cambridge {CAP} computer and its operating system},
isbn = {978-0-444-00357-7 978-0-444-00358-4},
series = {The computer science library operating and programming systems series},
pagetotal = {165},
number = {6},
publisher = {North Holland},
author = {Wilkes, Maurice V. and Needham, Roger M.},
date = {1979},
langid = {english},
file = {Wilkes and Needham - 1979 - The Cambridge CAP computer and its operating syste.pdf:/Users/akilan/Zotero/storage/VIQTWZS3/Wilkes and Needham - 1979 - The Cambridge CAP computer and its operating syste.pdf:application/pdf},
}
@article{fillo_mmachine_nodate,
title = {The M–Machine Multicomputer},
author = {Fillo, Marco and Keckler, Stephen W and Dally, William J and Carter, Nicholas P and Chang, Andrew and Gurevich, Yevgeny and Lee, Whay S},
langid = {english},
file = {Fillo et al. - The M–Machine Multicomputer.pdf:/Users/akilan/Zotero/storage/LD95UQTM/Fillo et al. - The M–Machine Multicomputer.pdf:application/pdf},
}
@inproceedings{kwon_low-fat_2013,
location = {New York, {NY}, {USA}},
title = {Low-fat pointers: compact encoding and efficient gate-level implementation of fat pointers for spatial safety and capability-based security},
isbn = {978-1-4503-2477-9},
url = {https://dl.acm.org/doi/10.1145/2508859.2516713},
doi = {10.1145/2508859.2516713},
series = {{CCS} '13},
shorttitle = {Low-fat pointers},
abstract = {Referencing outside the bounds of an array or buffer is a common source of bugs and security vulnerabilities in today's software. We can enforce spatial safety and eliminate these violations by inseparably associating bounds with every pointer (fat pointer) and checking these bounds on every memory access. By further adding hardware-managed tags to the pointer, we make them unforgeable. This, in turn, allows the pointers to be used as capabilities to facilitate fine-grained access control and fast security domain crossing. Dedicated checking hardware runs in parallel with the processor's normal datapath so that the checks do not slow down processor operation (0\% runtime overhead). To achieve the safety of fat pointers without increasing program state, we compactly encode approximate base and bound pointers along with exact address pointers for a 46b address space into one 64-bit word with a worst-case memory overhead of 3\%. We develop gate-level implementations of the logic for updating and validating these compact fat pointers and show that the hardware requirements are low and the critical paths for common operations are smaller than processor {ALU} operations. Specifically, we show that the fat-pointer check and update operations can run in a 4 ns clock cycle on a Virtex 6 (40nm) implementation while only using 1100 6-{LUTs} or about the area of a double-precision, floating-point adder.},
pages = {721--732},
booktitle = {Proceedings of the 2013 {ACM} {SIGSAC} conference on Computer \& communications security},
publisher = {Association for Computing Machinery},
author = {Kwon, Albert and Dhawan, Udit and Smith, Jonathan M. and Knight, Thomas F. and {DeHon}, Andre},
urldate = {2024-06-18},
date = {2013-11-04},
keywords = {capabilities, fat pointer, memory safety, processor, security, spatial confinement},
file = {Full Text PDF:/Users/akilan/Zotero/storage/CVVZYZS4/Kwon et al. - 2013 - Low-fat pointers compact encoding and efficient g.pdf:application/pdf},
}
@article{wulf_hydra_1974,
title = {{HYDRA}: the kernel of a multiprocessor operating system},
volume = {17},
issn = {0001-0782, 1557-7317},
url = {https://dl.acm.org/doi/10.1145/355616.364017},
doi = {10.1145/355616.364017},
shorttitle = {{HYDRA}},
abstract = {This paper describes the design philosophy of {HYDRA}—the kernel of an operating system for C.mmp, the Carnegie-Mellon Multi-Mini-Processor. This philosophy is realized through the introduction of a generalized notion of “resource,” both physical and virtual, called an “object.” Mechanisms are presented for dealing with objects, including the creation of new types, specification of new operations applicable to a given type, sharing, and protection of any reference to a given object against improper application of any of the operations defined with respect to that type of object. The mechanisms provide a coherent basis for extension of the system in two directions: the introduction of new facilities, and the creation of highly secure systems.},
pages = {337--345},
number = {6},
journaltitle = {Communications of the {ACM}},
shortjournal = {Commun. {ACM}},
author = {Wulf, W. and Cohen, E. and Corwin, W. and Jones, A. and Levin, R. and Pierson, C. and Pollack, F.},
urldate = {2024-06-18},
date = {1974-06},
langid = {english},
file = {Full Text:/Users/akilan/Zotero/storage/EIRBNTVF/Wulf et al. - 1974 - HYDRA the kernel of a multiprocessor operating sy.pdf:application/pdf},
}
@article{hardy_keykos_1985,
title = {{KeyKOS} architecture},
volume = {19},
issn = {0163-5980},
url = {https://dl.acm.org/doi/10.1145/858336.858337},
doi = {10.1145/858336.858337},
pages = {8--25},
number = {4},
journaltitle = {{ACM} {SIGOPS} Operating Systems Review},
shortjournal = {{SIGOPS} Oper. Syst. Rev.},
author = {Hardy, Norman},
urldate = {2024-06-18},
date = {1985-10-01},
file = {Full Text PDF:/Users/akilan/Zotero/storage/QSYKM6QN/Hardy - 1985 - KeyKOS architecture.pdf:application/pdf},
}
@article{rashid_mach_nodate,
title = {Mach: A System Software Kernel},
abstract = {The Mach operating system can be used as a system software kernel which can support a variety of operating system environments. Key elements of the Mach design which allow it to efficiently support system software include integrated virtual memory management and interprocess communication, multiple threads of control within one address space, support for transparent system trap callout and an object programming facility integrated with the Mach {IPC} mechanisms. Mach is currently available both from {CMU} and commercially on a wide range of uniprocessor and multiprocessor hardware.},
author = {Rashid, Richard and Julin, Daniel and Orr, Douglas and Sanzi, Richard and Baron, Robert and Forin, Alessandro and Golub, David and Jones, Michael},
langid = {english},
file = {Rashid et al. - Mach A System Software Kernel.pdf:/Users/akilan/Zotero/storage/UHLILYH9/Rashid et al. - Mach A System Software Kernel.pdf:application/pdf},
}
@inproceedings{baumann_multikernel_2009,
location = {Big Sky Montana {USA}},
title = {The multikernel: a new {OS} architecture for scalable multicore systems},
isbn = {978-1-60558-752-3},
url = {https://dl.acm.org/doi/10.1145/1629575.1629579},
doi = {10.1145/1629575.1629579},
shorttitle = {The multikernel},
abstract = {Commodity computer systems contain more and more processor cores and exhibit increasingly diverse architectural tradeoffs, including memory hierarchies, interconnects, instruction sets and variants, and {IO} configurations. Previous high-performance computing systems have scaled in specific cases, but the dynamic nature of modern client and server workloads, coupled with the impossibility of statically optimizing an {OS} for all workloads and hardware variants pose serious challenges for operating system structures.},
eventtitle = {{SOSP}09: {ACM} {SIGOPS} 22nd Symposium on Operating Systems Principles},
pages = {29--44},
booktitle = {Proceedings of the {ACM} {SIGOPS} 22nd symposium on Operating systems principles},
publisher = {{ACM}},
author = {Baumann, Andrew and Barham, Paul and Dagand, Pierre-Evariste and Harris, Tim and Isaacs, Rebecca and Peter, Simon and Roscoe, Timothy and Schüpbach, Adrian and Singhania, Akhilesh},
urldate = {2024-06-18},
date = {2009-10-11},
langid = {english},
file = {Baumann et al. - 2009 - The multikernel a new OS architecture for scalabl.pdf:/Users/akilan/Zotero/storage/4BVCRZN6/Baumann et al. - 2009 - The multikernel a new OS architecture for scalabl.pdf:application/pdf},
}
@article{watson_capsicum_nodate,
title = {Capsicum: practical capabilities for {UNIX}},
abstract = {Capsicum is a lightweight operating system capability and sandbox framework planned for inclusion in {FreeBSD} 9. Capsicum extends, rather than replaces, {UNIX} {APIs}, providing new kernel primitives (sandboxed capability mode and capabilities) and a userspace sandbox {API}. These tools support compartmentalisation of monolithic {UNIX} applications into logical applications, an increasingly common goal supported poorly by discretionary and mandatory access control. We demonstrate our approach by adapting core {FreeBSD} utilities and Google’s Chromium web browser to use Capsicum primitives, and compare the complexity and robustness of Capsicum with other sandboxing techniques.},
author = {Watson, Robert N M and Anderson, Jonathan and Kennaway, Kris and Laurie, Ben},
langid = {english},
file = {Watson et al. - Capsicum practical capabilities for UNIX.pdf:/Users/akilan/Zotero/storage/IAFXHJ8H/Watson et al. - Capsicum practical capabilities for UNIX.pdf:application/pdf},
}
@online{noauthor_department_nodate,
title = {Department of Computer Science and Technology: {CheriBSD}},
url = {https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheribsd.html},
urldate = {2024-06-18},
file = {Department of Computer Science and Technology\: CheriBSD:/Users/akilan/Zotero/storage/3XQJWCXD/cheribsd.html:text/html},
}
@online{noauthor_msrc-security-researchpapers2020security_nodate,
title = {{MSRC}-Security-Research/papers/2020/Security analysis of {CHERI} {ISA}.pdf at master · microsoft/{MSRC}-Security-Research},
url = {https://github.com/microsoft/MSRC-Security-Research/blob/master/papers/2020/Security%20analysis%20of%20CHERI%20ISA.pdf},
abstract = {Security Research from the Microsoft Security Response Center ({MSRC}) - microsoft/{MSRC}-Security-Research},
titleaddon = {{GitHub}},
urldate = {2024-06-18},
langid = {english},
file = {Snapshot:/Users/akilan/Zotero/storage/ENF2KYRT/Security analysis of CHERI ISA.html:text/html},
}
@inproceedings{zaliva_formal_2024,
location = {La Jolla {CA} {USA}},
title = {Formal Mechanised Semantics of {CHERI} C: Capabilities, Undefined Behaviour, and Provenance},
isbn = {9798400703720},
url = {https://dl.acm.org/doi/10.1145/3617232.3624859},
doi = {10.1145/3617232.3624859},
shorttitle = {Formal Mechanised Semantics of {CHERI} C},
abstract = {Memory safety issues are a persistent source of security vulnerabilities, with conventional architectures and the C codebase chronically prone to exploitable errors. The {CHERI} research project has shown how one can provide radically improved security for that existing codebase with minimal modification, using unforgeable hardware capabilities in place of machine-word pointers in {CHERI} dialects of C, implemented as adaptions of Clang/{LLVM} and {GCC}. {CHERI} was first prototyped as extensions of {MIPS} and {RISC}-V; it is currently being evaluated by Arm and others with the Arm Morello experimental architecture, processor, and platform, to explore its potential for mass-market adoption, and by Microsoft in their {CHERIoT} design for embedded cores.},
eventtitle = {{ASPLOS} '24: 29th {ACM} International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1},
pages = {181--196},
booktitle = {Proceedings of the 29th {ACM} International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 1},
publisher = {{ACM}},
author = {Zaliva, Vadim and Memarian, Kayvan and Almeida, Ricardo and Clarke, Jessica and Davis, Brooks and Richardson, Alexander and Chisnall, David and Campbell, Brian and Stark, Ian and Watson, Robert N. M. and Sewell, Peter},
urldate = {2024-06-18},
date = {2024-04-27},
langid = {english},
file = {Zaliva et al. - 2024 - Formal Mechanised Semantics of CHERI C Capabiliti.pdf:/Users/akilan/Zotero/storage/8Y2CRHBS/Zaliva et al. - 2024 - Formal Mechanised Semantics of CHERI C Capabiliti.pdf:application/pdf},
}
@article{watson_cheri_nodate,
title = {{CHERI} C/C++ Programming Guide},
abstract = {This document is a brief introduction to the {CHERI} C/C++ programming languages. We explain the principles underlying these language variants, and their grounding in {CHERI}’s multiple architectural instantiations: {CHERI}-{MIPS}, {CHERI}-{RISC}-V, and Arm’s Morello. We describe the most commonly encountered differences between these dialects and C/C++ on conventional architectures, and where existing software may require minor changes. We document new compiler warnings and errors that may be experienced compiling code with the {CHERI} Clang/{LLVM} compiler, and suggest how they may be addressed through typically minor source-code changes. We explain how modest language extensions allow selected software, such as memory allocators, to further refine permissions and bounds on pointers. This guidance is based on our experience adapting the {FreeBSD} operating-system userspace, and applications such as {PostgreSQL} and {WebKit}, to run in a {CHERI} C/C++ capability-based programming environment. We conclude by recommending further reading.},
author = {Watson, Robert N M and Richardson, Alexander and Davis, Brooks and Baldwin, John and Chisnall, David and Clarke, Jessica and Filardo, Nathaniel and Moore, Simon W and Napierala, Edward and Sewell, Peter and Neumann, Peter G},
langid = {english},
file = {Watson et al. - CHERI CC++ Programming Guide.pdf:/Users/akilan/Zotero/storage/WHGQXE8P/Watson et al. - CHERI CC++ Programming Guide.pdf:application/pdf},
}
@article{esswood_cherios_nodate-1,
title = {{CheriOS}: designing an untrusted single-address-space capability operating system utilising capability hardware and a minimal hypervisor},
author = {Esswood, Lawrence G},
langid = {english},
file = {Esswood - CheriOS designing an untrusted single-address-spa.pdf:/Users/akilan/Zotero/storage/3IVKGYZ5/Esswood - CheriOS designing an untrusted single-address-spa.pdf:application/pdf},
}
@online{noauthor_architecture_nodate,
title = {The Architecture  of the Burroughs B-5000},
url = {https://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm},
urldate = {2024-06-18},
file = {The Architecture  of the Burroughs B-5000:/Users/akilan/Zotero/storage/ELNL8VBQ/The Architecture of the Burroughs B-5000.html:text/html},
}
@article{dennis_programming_1966,
title = {Programming semantics for multiprogrammed computations},
volume = {9},
issn = {0001-0782, 1557-7317},
url = {https://dl.acm.org/doi/10.1145/365230.365252},
doi = {10.1145/365230.365252},
abstract = {The semantics are defined for a number of meta-instructions which perform operations essential to the writing of programs in multiprogrammed computer systems. These meta-instructions relate to parallel processing, protecting of separate computations, program debugging, and the sharing among users of memory segments and other computing objects, the names of which are hierarchically structured. The language sophistication contemplated is midway between an assembly language and an advanced algebraic language.},
pages = {143--155},
number = {3},
journaltitle = {Communications of the {ACM}},
shortjournal = {Commun. {ACM}},
author = {Dennis, Jack B. and Van Horn, Earl C.},
urldate = {2024-06-18},
date = {1966-03},
langid = {english},
file = {Full Text:/Users/akilan/Zotero/storage/6MLX2U8V/Dennis and Van Horn - 1966 - Programming semantics for multiprogrammed computat.pdf:application/pdf},
}
@article{watson_capability_nodate,
title = {Capability Hardware Enhanced {RISC} Instructions: {CHERI} Instruction-Set Architecture (Version 8)},
abstract = {This technical report describes {CHERI} {ISAv}8, the eighth version of the {CHERI} architecture being developed by {SRI} International and the University of Cambridge. This design captures ten years of research, development, experimentation, refinement, formal analysis, and validation through hardware and software implementation.},
author = {Watson, Robert N M and Neumann, Peter G and Woodruff, Jonathan and Roe, Michael and Almatary, Hesham and Anderson, Jonathan and Baldwin, John and Barnes, Graeme and Chisnall, David and Clarke, Jessica and Davis, Brooks and Eisen, Lee and Filardo, Nathaniel Wesley and Grisenthwaite, Richard and Joannou, Alexandre and Laurie, Ben and Markettos, A Theodore and Moore, Simon W and Murdoch, Steven J and Nienhuis, Kyndylan and Norton, Robert and Richardson, Alexander and Rugg, Peter and Sewell, Peter and Son, Stacey and Xia, Hongyan},
langid = {english},
file = {Watson et al. - Capability Hardware Enhanced RISC Instructions CH.pdf:/Users/akilan/Zotero/storage/R9T374YS/Watson et al. - Capability Hardware Enhanced RISC Instructions CH.pdf:application/pdf},
}
@online{noauthor_-it-yourself_nodate,
title = {Do-It-Yourself Virtual Memory Translation {\textbar} {ACM} {SIGARCH} Computer Architecture News},
url = {https://dl.acm.org/doi/10.1145/3140659.3080209},
urldate = {2024-06-18},
}
@online{noauthor_osdi_nodate,
title = {{OSDI} Symposia {\textbar} {USENIX}},
url = {https://www.usenix.org/conferences/byname/179},
urldate = {2024-06-19},
file = {OSDI Symposia | USENIX:/Users/akilan/Zotero/storage/VI7YCLJV/179.html:text/html},
}
@article{mittal_survey_2017,
title = {A survey of techniques for architecting {TLBs}},
volume = {29},
rights = {Copyright © 2016 John Wiley \& Sons, Ltd.},
issn = {1532-0634},
url = {https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.4061},
doi = {10.1002/cpe.4061},
abstract = {Translation lookaside buffer ({TLB}) caches virtual to physical address translation information and is used in systems ranging from embedded devices to high-end servers. Because {TLB} is accessed very frequently and a {TLB} miss is extremely costly, prudent management of {TLB} is important for improving performance and energy efficiency of processors. In this paper, we present a survey of techniques for architecting and managing {TLBs}. We characterize the techniques across several dimensions to highlight their similarities and distinctions. We believe that this paper will be useful for chip designers, computer architects, and system engineers.},
pages = {e4061},
number = {10},
journaltitle = {Concurrency and Computation: Practice and Experience},
author = {Mittal, Sparsh},
urldate = {2024-06-24},
date = {2017},
langid = {english},
note = {\_eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/cpe.4061},
keywords = {classification, power management, prefetching, Review, superpage, {TLB}, virtual cache, workload characterization},
file = {Snapshot:/Users/akilan/Zotero/storage/JJ9H6B2H/cpe.html:text/html},
}
@inproceedings{lietar_snmalloc_2019,
location = {New York, {NY}, {USA}},
title = {snmalloc: a message passing allocator},
isbn = {978-1-4503-6722-6},
url = {https://doi.org/10.1145/3315573.3329980},
doi = {10.1145/3315573.3329980},
series = {{ISMM} 2019},
shorttitle = {snmalloc},
abstract = {snmalloc is an implementation of malloc aimed at workloads in which objects are typically deallocated by a different thread than the one that had allocated them. We use the term producer/consumer for such workloads. snmalloc uses a novel message passing scheme which returns deallocated objects to the originating allocator in batches without taking any locks. It also uses a novel bump pointer-free list data structure with which just 64-bits of meta-data are sufficient for each 64 {KiB} slab. On such producer/consumer benchmarks our approach performs better than existing allocators. Snmalloc is available at {\textless}a href="https://github.com/Microsoft/snmalloc"{\textgreater}https://github.com/Microsoft/snmalloc{\textless}/a{\textgreater}.},
pages = {122--135},
booktitle = {Proceedings of the 2019 {ACM} {SIGPLAN} International Symposium on Memory Management},
publisher = {Association for Computing Machinery},
author = {Liétar, Paul and Butler, Theodore and Clebsch, Sylvan and Drossopoulou, Sophia and Franco, Juliana and Parkinson, Matthew J. and Shamis, Alex and Wintersteiger, Christoph M. and Chisnall, David},
urldate = {2024-06-23},
date = {2019-06-23},
keywords = {Memory allocation, message passing},
}

62
docs/introduction/introduction.org Normal file
View File

@@ -0,0 +1,62 @@
* Introduction
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 larger and 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 TLB utilisation 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 several ways, such as speeding
up memory-intensive applications, reducing latency in data access, and enhancing throughput for
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, present 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 CHERI’s compressed\cite{woodruff_cheri_2019} encoded bounds with the use of huge pages, it becomes possible to track and manage
large, physically contiguous memory blocks more efficiently. This combination reduces 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 fragmented or non-contiguous
memory allocations. The contributions for the following paper are as follows:
- **Fat-pointer Based Range Addresses**: Introduces fat-pointers that include memory bounds, allowing
efficient tracking and management of physically contiguous memory regions.
- **Custom Memory Allocation with Huge Pages**: Proposes a custom `mmap` function and
kernel module for allocating huge pages of physically contiguous memory, reducing the need for traditional
TLB entries and improving efficiency.
- **Novel Memory Allocation Algorithms**: Provides new algorithms for allocating and freeing
physically contiguous memory, integrating huge pages with CHERI’s capability-based bounds for enhanced memory management.
- **CHERI’s 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.
Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s 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
high memory throughput and low translation overhead. The following below are research questions
we are addressing:
1. How does the utilization of bounds for tracking memory allocations, in addition to security purposes, affect the
run times and Translation Lookaside Buffer (TLB) miss rates in modern computing systems?
2. How does the implementation of bounds for seeking through physically contiguous memory influence the complexity and
efficiency of standard memory allocators, particularly those with advanced features such as transparent
huge pages, and what are the implications for system performance in terms of execution speed, memory access
latency, and resource utilization?
\bibliographystyle{IEEEtran}
\bibliography{introduction.bib}

62
docs/introduction/introduction.org~ Normal file
View File

@@ -0,0 +1,62 @@
* Introduction
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 larger and 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 TLB utilisation 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 several ways, such as speeding
up memory-intensive applications, reducing latency in data access, and enhancing throughput for
workloads that rely heavily on large datasets.
Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
architecture, present 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 CHERI’s compressed encoded bounds with the use of huge pages, it becomes possible to track and manage
large, physically contiguous memory blocks more efficiently. This combination reduces 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 fragmented or non-contiguous
memory allocations. The contributions for the following paper are as follows:
- **Fat-pointer Based Range Addresses**: Introduces fat-pointers that include memory bounds, allowing
efficient tracking and management of physically contiguous memory regions.
- **Custom Memory Allocation with Huge Pages**: Proposes a custom `mmap` function and
kernel module for allocating huge pages of physically contiguous memory, reducing the need for traditional
TLB entries and improving efficiency.
- **Novel Memory Allocation Algorithms**: Provides new algorithms for allocating and freeing
physically contiguous memory, integrating huge pages with CHERI’s capability-based bounds for enhanced memory management.
- **CHERI’s 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.
Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s 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
high memory throughput and low translation overhead. The following below are research questions
we are addressing:
1. How does the utilization of bounds for tracking memory allocations, in addition to security purposes, affect the
run times and Translation Lookaside Buffer (TLB) miss rates in modern computing systems?
2. How does the implementation of bounds for seeking through physically contiguous memory influence the complexity and
efficiency of standard memory allocators, particularly those with advanced features such as transparent
huge pages, and what are the implications for system performance in terms of execution speed, memory access
latency, and resource utilization?
\bibliographystyle{IEEEtran}
\bibliography{introduction.bib}

BIN
docs/introduction/introduction.pdf Normal file
View File

Binary file not shown.

95
docs/introduction/introduction.tex Normal file
View File

@@ -0,0 +1,95 @@
% Created 2025-01-20 Mon 13:33
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\author{Akilan}
\date{\today}
\title{}
\hypersetup{
pdfauthor={Akilan},
pdftitle={},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 29.1 (Org mode 9.6.6)},
pdflang={English}}
\begin{document}
\tableofcontents
\section{Introduction}
\label{sec:org01b31aa}
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 larger and 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 TLB utilisation 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 several ways, such as speeding
up memory-intensive applications, reducing latency in data access, and enhancing throughput for
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, present 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 CHERI’s compressed\cite{woodruff_cheri_2019} encoded bounds with the use of huge pages, it becomes possible to track and manage
large, physically contiguous memory blocks more efficiently. This combination reduces 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 fragmented or non-contiguous
memory allocations. The contributions for the following paper are as follows:
\begin{itemize}
\item \textbf{\textbf{Fat-pointer Based Range Addresses}}: Introduces fat-pointers that include memory bounds, allowing
efficient tracking and management of physically contiguous memory regions.
\item \textbf{\textbf{Custom Memory Allocation with Huge Pages}}: Proposes a custom `mmap` function and
kernel module for allocating huge pages of physically contiguous memory, reducing the need for traditional
TLB entries and improving efficiency.
\item \textbf{\textbf{Novel Memory Allocation Algorithms}}: Provides new algorithms for allocating and freeing
physically contiguous memory, integrating huge pages with CHERI’s capability-based bounds for enhanced memory management.
\item \textbf{\textbf{CHERI’s 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.
\end{itemize}
Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s 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
high memory throughput and low translation overhead. The following below are research questions
we are addressing:
\begin{enumerate}
\item How does the utilization of bounds for tracking memory allocations, in addition to security purposes, affect the
run times and Translation Lookaside Buffer (TLB) miss rates in modern computing systems?
\item How does the implementation of bounds for seeking through physically contiguous memory influence the complexity and
efficiency of standard memory allocators, particularly those with advanced features such as transparent
huge pages, and what are the implications for system performance in terms of execution speed, memory access
latency, and resource utilization?
\end{enumerate}
\bibliographystyle{IEEEtran}
\bibliography{introduction.bib}
\end{document}

8
dpdk/kernel/freebsd/Hugepage/BSDmakefile Normal file
View File

@@ -0,0 +1,8 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
#
KMOD= Hugepage
SRCS= Hugepage.c device_if.h bus_if.h
.include <bsd.kmod.mk>

518
dpdk/kernel/freebsd/Hugepage/Hugepage.c Normal file
View File

@@ -0,0 +1,518 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2010-2014 Intel Corporation
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/bio.h>
#include <sys/bus.h>
#include <sys/conf.h>
#include <sys/kernel.h>
#include <sys/malloc.h>
#include <sys/module.h>
#include <sys/proc.h>
#include <sys/lock.h>
#include <sys/rwlock.h>
#include <sys/mutex.h>
#include <sys/systm.h>
#include <sys/sysctl.h>
#include <sys/vmmeter.h>
#include <sys/eventhandler.h>
#include <machine/bus.h>
#include <vm/vm.h>
#include <vm/pmap.h>
#include <vm/vm_param.h>
#include <vm/vm_object.h>
#include <vm/vm_page.h>
#include <vm/vm_pager.h>
#include <vm/vm_phys.h>
// #include <cheriintrin.h>
#include <cheri/cheric.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
// #include <fcntl.h>
// #include <assert.h>
// #include <stdlib.h>
#include <sys/time.h>
#include <sys/errno.h>
// #include <stdint.h>
// #include <stdio.h>
// #include <unistd.h>
// #include <stddef.h>
// #include <stdlib.h>
// #include <string.h>
// added to print uint
// 64
// #include <inttypes.h>
struct contigmem_buffer {
void *addr;
int refcnt;
struct mtx mtx;
};
struct contigmem_vm_handle {
int buffer_index;
};
static int contigmem_load(void);
static int contigmem_unload(void);
static int contigmem_physaddr(SYSCTL_HANDLER_ARGS);
static d_mmap_single_t contigmem_mmap_single;
static d_open_t contigmem_open;
static d_close_t contigmem_close;
static int contigmem_num_buffers = RTE_CONTIGMEM_DEFAULT_NUM_BUFS;
static int64_t contigmem_buffer_size = RTE_CONTIGMEM_DEFAULT_BUF_SIZE;
static eventhandler_tag contigmem_eh_tag;
static struct contigmem_buffer contigmem_buffers[RTE_CONTIGMEM_MAX_NUM_BUFS];
static struct cdev *contigmem_cdev = NULL;
static int contigmem_refcnt;
TUNABLE_INT("hw.contigmem.num_buffers", &contigmem_num_buffers);
TUNABLE_QUAD("hw.contigmem.buffer_size", &contigmem_buffer_size);
static SYSCTL_NODE(_hw, OID_AUTO, contigmem, CTLFLAG_RD, 0, "contigmem");
SYSCTL_INT(_hw_contigmem, OID_AUTO, num_buffers, CTLFLAG_RD,
&contigmem_num_buffers, 0, "Number of contigmem buffers allocated");
SYSCTL_QUAD(_hw_contigmem, OID_AUTO, buffer_size, CTLFLAG_RD,
&contigmem_buffer_size, 0, "Size of each contiguous buffer");
SYSCTL_INT(_hw_contigmem, OID_AUTO, num_references, CTLFLAG_RD,
&contigmem_refcnt, 0, "Number of references to contigmem");
static SYSCTL_NODE(_hw_contigmem, OID_AUTO, physaddr, CTLFLAG_RD, 0,
"physaddr");
MALLOC_DEFINE(M_CONTIGMEM, "customcontigmem", "customcontigmem(4) allocations");
void *ptr;
int MallocCounter;
#define MAXPAGESIZES 2
/*
* The offset in sysent where the syscall is allocated.
*/
static int offset = NO_SYSCALL;
static int contigmem_modevent(module_t mod, int type, void *arg)
{
int error = 0;
switch (type) {
case MOD_LOAD:
error = contigmem_load();
break;
case MOD_UNLOAD:
error = contigmem_unload();
break;
default:
break;
}
return error;
}
moduledata_t contigmem_mod = {
"contigmem",
(modeventhand_t)contigmem_modevent,
0
};
DECLARE_MODULE(contigmem, contigmem_mod, SI_SUB_DRIVERS, SI_ORDER_ANY);
MODULE_VERSION(contigmem, 1);
static struct cdevsw contigmem_ops = {
.d_name = "contigmem",
.d_version = D_VERSION,
.d_flags = D_TRACKCLOSE,
.d_mmap_single = contigmem_mmap_single,
.d_open = contigmem_open,
.d_close = contigmem_close,
};
static int
pagesizes(size_t ps[MAXPAGESIZES])
{
int pscnt;
pscnt = getpagesizes(ps, MAXPAGESIZES);
// ATF_REQUIRE_MSG(pscnt != -1, "getpagesizes failed; errno=%d", errno);
// ATF_REQUIRE_MSG(ps[0] != 0, "psind 0 is %zu", ps[0]);
// ATF_REQUIRE_MSG(pscnt <= MAXPAGESIZES, "invalid pscnt %d", pscnt);
// if (pscnt == 1){
// printf("pscnt is 1");
// }
// atf_tc_skip("no large page support");
return (pscnt);
}
static int
contigmem_load()
{
size_t sz;
// Pre Allocate 1GB huge page
sz = 1073741824;
int error, fd, pscnt, pn;
size_t ps[MAXPAGESIZES];
size_t size[3];
pn = getpagesizes(size, 3);
printf("page size is [%d]", size[2]);
pscnt = pagesizes(ps);
fd = shm_create_largepage(SHM_ANON, O_CREAT | O_RDWR, 1, SHM_LARGEPAGE_ALLOC_DEFAULT, 0);
if (fd < 0 && errno == ENOTTY) {
// perror("sh_create_largepages");
close(fd);
}
// if (fd < 0)
// perror("no large page supported");
// exit(EXIT_FAILURE);
// if (fd < 0 && errno == ENOTTY)
// atf_tc_skip("no large page support");
// ATF_REQUIRE_MSG(fd >= 0, "shm_create_largepage failed; errno=%d", errno);
if (ftruncate(fd, sz) < 0) {
// perror("ftruncate");
close(fd);
}
// if (error != 0 && errno == ENOMEM)
// /*
// * The test system might not have enough memory to accommodate
// * the request.
// */
// atf_tc_skip("failed to allocate %zu-byte superpage", sz);
// ATF_REQUIRE_MSG(error == 0, "ftruncate failed; errno=%d", errno);
ptr = mmap(NULL, sz,
PROT_READ|PROT_WRITE, MAP_SHARED,fd,0);
// Added error handling
if(ptr == MAP_FAILED)
{
// perror("mmap");
exit(EXIT_FAILURE);
}
MallocCounter = (int)sz;
return 0;
}
static int
contigmem_unload()
{
// int i;
// if (contigmem_refcnt > 0)
// return EBUSY;
// if (contigmem_cdev != NULL)
// destroy_dev(contigmem_cdev);
// if (contigmem_eh_tag != NULL)
// EVENTHANDLER_DEREGISTER(process_exit, contigmem_eh_tag);
// for (i = 0; i < RTE_CONTIGMEM_MAX_NUM_BUFS; i++) {
// if (contigmem_buffers[i].addr != NULL)
// contigfree(contigmem_buffers[i].addr,
// contigmem_buffer_size, M_CONTIGMEM);
// if (mtx_initialized(&contigmem_buffers[i].mtx))
// mtx_destroy(&contigmem_buffers[i].mtx);
// }
// printf("free called \n");
// get bounds from
// printf("free len %d \n", len);
// Free the entire huge page
munmap(ptr, 1073741824);
return 0;
}
static int
contigmem_physaddr(SYSCTL_HANDLER_ARGS)
{
uint64_t physaddr;
int index = (int)(uintptr_t)arg1;
physaddr = (uint64_t)vtophys(contigmem_buffers[index].addr);
return sysctl_handle_64(oidp, &physaddr, 0, req);
}
static int
contigmem_open(struct cdev *cdev, int fflags, int devtype,
struct thread *td)
{
printf("Contigmem opened \n");
atomic_add_int(&contigmem_refcnt, 1);
return 0;
}
static int
contigmem_close(struct cdev *cdev, int fflags, int devtype,
struct thread *td)
{
atomic_subtract_int(&contigmem_refcnt, 1);
return 0;
}
static int
contigmem_cdev_pager_ctor(void *handle, vm_ooffset_t size, vm_prot_t prot,
vm_ooffset_t foff, struct ucred *cred, u_short *color)
{
struct contigmem_vm_handle *vmh = handle;
struct contigmem_buffer *buf;
buf = &contigmem_buffers[vmh->buffer_index];
atomic_add_int(&contigmem_refcnt, 1);
mtx_lock(&buf->mtx);
if (buf->refcnt == 0)
memset(buf->addr, 0, contigmem_buffer_size);
buf->refcnt++;
mtx_unlock(&buf->mtx);
return 0;
}
static void
contigmem_cdev_pager_dtor(void *handle)
{
struct contigmem_vm_handle *vmh = handle;
struct contigmem_buffer *buf;
buf = &contigmem_buffers[vmh->buffer_index];
mtx_lock(&buf->mtx);
buf->refcnt--;
mtx_unlock(&buf->mtx);
free(vmh, M_CONTIGMEM);
atomic_subtract_int(&contigmem_refcnt, 1);
}
static int
contigmem_cdev_pager_fault(vm_object_t object, vm_ooffset_t offset, int prot,
vm_page_t *mres)
{
vm_paddr_t paddr;
vm_page_t m_paddr, page;
vm_memattr_t memattr, memattr1;
memattr = object->memattr;
VM_OBJECT_WUNLOCK(object);
paddr = offset;
m_paddr = vm_phys_paddr_to_vm_page(paddr);
if (m_paddr != NULL) {
memattr1 = pmap_page_get_memattr(m_paddr);
if (memattr1 != memattr)
memattr = memattr1;
}
if (((*mres)->flags & PG_FICTITIOUS) != 0) {
/*
* If the passed in result page is a fake page, update it with
* the new physical address.
*/
page = *mres;
VM_OBJECT_WLOCK(object);
vm_page_updatefake(page, paddr, memattr);
} else {
/*
* Replace the passed in reqpage page with our own fake page and
* free up the original page.
*/
page = vm_page_getfake(paddr, memattr);
VM_OBJECT_WLOCK(object);
#if __FreeBSD__ >= 13
vm_page_replace(page, object, (*mres)->pindex, *mres);
#else
vm_page_t mret = vm_page_replace(page, object, (*mres)->pindex);
KASSERT(mret == *mres,
("invalid page replacement, old=%p, ret=%p", *mres, mret));
vm_page_lock(mret);
vm_page_free(mret);
vm_page_unlock(mret);
#endif
*mres = page;
}
page->valid = VM_PAGE_BITS_ALL;
return VM_PAGER_OK;
}
static struct cdev_pager_ops contigmem_cdev_pager_ops = {
.cdev_pg_ctor = contigmem_cdev_pager_ctor,
.cdev_pg_dtor = contigmem_cdev_pager_dtor,
.cdev_pg_fault = contigmem_cdev_pager_fault,
};
static int
(struct cdev *cdev, vm_ooffset_t *offset, vm_size_t size,
struct vm_object **obj, int nprot)
{
// Testing if this is called when file is opened
printf("contigmem_mmap_single called \n");
// struct contigmem_vm_handle *vmh;
// uint64_t buffer_index;
// /*
// * The buffer index is encoded in the offset. Divide the offset by
// * PAGE_SIZE to get the index of the buffer requested by the user
// * app.
// */
// buffer_index = *offset / PAGE_SIZE;
// if (buffer_index >= contigmem_num_buffers)
// return EINVAL;
// if (size > contigmem_buffer_size)
// return EINVAL;
// vmh = malloc(sizeof(*vmh), M_CONTIGMEM, M_NOWAIT | M_ZERO);
// if (vmh == NULL)
// return ENOMEM;
// vmh->buffer_index = buffer_index;
// *offset = (vm_ooffset_t)vtophys(contigmem_buffers[buffer_index].addr);
// *obj = cdev_pager_allocate(vmh, OBJT_DEVICE, &contigmem_cdev_pager_ops,
// size, nprot, *offset, curthread->td_ucred);
size = __builtin_align_up(size, _Alignof(max_align_t));
// printf("%d \n", sz);
// printf("%d Malloc counter\n", MallocCounter);
MallocCounter -= size;
obj = &ptr[MallocCounter];
obj = cheri_setbounds(obj, sz);
return 0;
}
// SAMPLE SYSCALL IMPLEMENTATION
// /*-
// * SPDX-License-Identifier: BSD-2-Clause
// *
// * Copyright (c) 1999 Assar Westerlund
// * All rights reserved.
// *
// * Redistribution and use in source and binary forms, with or without
// * modification, are permitted provided that the following conditions
// * are met:
// * 1. Redistributions of source code must retain the above copyright
// * notice, this list of conditions and the following disclaimer.
// * 2. Redistributions in binary form must reproduce the above copyright
// * notice, this list of conditions and the following disclaimer in the
// * documentation and/or other materials provided with the distribution.
// *
// * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
// * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
// * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
// * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
// * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
// * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
// * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
// * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
// * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
// * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
// * SUCH DAMAGE.
// */
// #include <sys/param.h>
// #include <sys/proc.h>
// #include <sys/module.h>
// #include <sys/sysproto.h>
// #include <sys/sysent.h>
// #include <sys/kernel.h>
// #include <sys/systm.h>
// /*
// * The function for implementing the syscall.
// */
// static int
// hello(struct thread *td, void *arg)
// {
// printf("hello kernel\n");
// return (0);
// }
// /*
// * The `sysent' for the new syscall
// */
// static struct sysent hello_sysent = {
// .sy_narg = 0,
// .sy_call = hello
// };
// /*
// * The offset in sysent where the syscall is allocated.
// */
// static int offset = NO_SYSCALL;
// /*
// * The function called at load/unload.
// */
// static int
// load(struct module *module, int cmd, void *arg)
// {
// int error = 0;
// switch (cmd) {
// case MOD_LOAD :
// printf("syscall loaded at %d\n", offset);
// break;
// case MOD_UNLOAD :
// printf("syscall unloaded from %d\n", offset);
// break;
// default :
// error = EOPNOTSUPP;
// break;
// }
// return (error);
// }
// SYSCALL_MODULE(syscall, &offset, &hello_sysent, load, NULL);

4
dpdk/kernel/freebsd/Hugepage/meson.build Normal file
View File

@@ -0,0 +1,4 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
sources = files('Hugepage.c')

2
dpdk/kernel/freebsd/meson.build
View File

@@ -2,7 +2,7 @@
#SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2018 Intel Corporation
kmods = ['contigmem', 'nic_uio']
kmods = ['Hugepage', 'nic_uio']
# for building kernel modules, we use kernel build system using make, as
# with Linux. We have a skeleton BSDmakefile, which pulls many of its

2
localpush.sh
View File

@@ -2,5 +2,5 @@ files=`find . -newermt "-3600 secs" | sed 's|^./||'`
for file in $files
do
sshpass -p "" scp "$file" "akilan@192.168.0.10:/home/akilan/Alloc-Test/CHERI-Allocator/$file"
scp -P 40515 "$file" "akilan@217.76.63.222:/home/akilan/Alloc-Test/CHERI-Allocator/$file"
done