added sections of the evaluation report
This commit is contained in:
471
KernelModule/customMemAlloc.c
Normal file
471
KernelModule/customMemAlloc.c
Normal file
@@ -0,0 +1,471 @@
|
||||
/* 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>
|
||||
|
||||
// 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");
|
||||
|
||||
|
||||
/*
|
||||
* 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
|
||||
contigmem_load()
|
||||
{
|
||||
|
||||
// get page size
|
||||
printf("%d FreeBSD page size \n",PAGE_SIZE);
|
||||
|
||||
char index_string[8], description[32];
|
||||
int i, error = 0;
|
||||
void *addr;
|
||||
|
||||
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;
|
||||
}
|
||||
|
||||
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;
|
||||
}
|
||||
|
||||
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;
|
||||
}
|
||||
|
||||
#ifndef RTE_ARCH_ARM_PURECAP_HACK
|
||||
printf("%2u: virt=%p phys=%p\n", i, addr,
|
||||
(void *)pmap_kextract((vm_offset_t)addr));
|
||||
#endif
|
||||
|
||||
mtx_init(&contigmem_buffers[i].mtx, "contigmem", NULL, MTX_DEF);
|
||||
contigmem_buffers[i].addr = addr;
|
||||
contigmem_buffers[i].refcnt = 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);
|
||||
}
|
||||
|
||||
contigmem_cdev = make_dev_credf(0, &contigmem_ops, 0, NULL, UID_ROOT,
|
||||
GID_WHEEL, 0600, "contigmem");
|
||||
|
||||
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
|
||||
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);
|
||||
}
|
||||
|
||||
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
|
||||
contigmem_mmap_single(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);
|
||||
|
||||
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);
|
||||
@@ -8,8 +8,8 @@ This will consist of a paragraph of the following structure:
|
||||
** Expirement setup
|
||||
- Mentions about the CHERI board used.
|
||||
- specs of the board
|
||||
- mentions about the compiled flag called benchmark ABI.(https://ctsrd-cheri.github.io/morello-early-performance-results/performance-methodology/abis-code-generation-and-compilation.html)
|
||||
- mentions how the various benchmark are compared and breifly
|
||||
- mentions about the compiled flag called benchmark ABI.
|
||||
- mentions how the various bechmark are compared and breifly
|
||||
mentions about the ARM performance counters.
|
||||
|
||||
** Performance counters used
|
||||
@@ -20,7 +20,8 @@ This will consist of a paragraph of the following structure:
|
||||
This is more in a bulletin point manner.
|
||||
|
||||
** Graphs listed
|
||||
- Talks about each of the benchmark patterns indenpendently (Bulletin points elaborated).
|
||||
- Talks about each of the benchmark patterns indenpendently
|
||||
(Bulletin points elaborated).
|
||||
- Builds up on those with multiple runs.
|
||||
|
||||
** Usability:
|
||||
@@ -28,4 +29,4 @@ Talk about the ease of running the new allocator.
|
||||
- Limitaion why certain benchmarks did not work.
|
||||
- The eager Huge page design while designed for fragmentation can still incur fragmentation at
|
||||
a user level.
|
||||
- How was the memory allocator swapped.
|
||||
- How was the memory allocator swapped.
|
||||
@@ -20,7 +20,8 @@ This will consist of a paragraph of the following structure:
|
||||
This is more in a bulletin point manner.
|
||||
|
||||
** Graphs listed
|
||||
- Talks about each of the benchmark patterns indenpendently (Bulletin points elaborated).
|
||||
- Talks about each of the benchmark patterns indenpendently
|
||||
(Bulletin points elaborated).
|
||||
- Builds up on those with multiple runs.
|
||||
|
||||
** Usability:
|
||||
|
||||
482
docs/evaluation/evaluation.html
Normal file
482
docs/evaluation/evaluation.html
Normal file
@@ -0,0 +1,482 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||||
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
|
||||
<head>
|
||||
<!-- 2025-01-12 Sun 17:26 -->
|
||||
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>‎</title>
|
||||
<meta name="author" content="Akilan" />
|
||||
<meta name="generator" content="Org Mode" />
|
||||
<style>
|
||||
#content { max-width: 60em; margin: auto; }
|
||||
.title { text-align: center;
|
||||
margin-bottom: .2em; }
|
||||
.subtitle { text-align: center;
|
||||
font-size: medium;
|
||||
font-weight: bold;
|
||||
margin-top:0; }
|
||||
.todo { font-family: monospace; color: red; }
|
||||
.done { font-family: monospace; color: green; }
|
||||
.priority { font-family: monospace; color: orange; }
|
||||
.tag { background-color: #eee; font-family: monospace;
|
||||
padding: 2px; font-size: 80%; font-weight: normal; }
|
||||
.timestamp { color: #bebebe; }
|
||||
.timestamp-kwd { color: #5f9ea0; }
|
||||
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
|
||||
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
|
||||
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
|
||||
.underline { text-decoration: underline; }
|
||||
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
|
||||
p.verse { margin-left: 3%; }
|
||||
pre {
|
||||
border: 1px solid #e6e6e6;
|
||||
border-radius: 3px;
|
||||
background-color: #f2f2f2;
|
||||
padding: 8pt;
|
||||
font-family: monospace;
|
||||
overflow: auto;
|
||||
margin: 1.2em;
|
||||
}
|
||||
pre.src {
|
||||
position: relative;
|
||||
overflow: auto;
|
||||
}
|
||||
pre.src:before {
|
||||
display: none;
|
||||
position: absolute;
|
||||
top: -8px;
|
||||
right: 12px;
|
||||
padding: 3px;
|
||||
color: #555;
|
||||
background-color: #f2f2f299;
|
||||
}
|
||||
pre.src:hover:before { display: inline; margin-top: 14px;}
|
||||
/* Languages per Org manual */
|
||||
pre.src-asymptote:before { content: 'Asymptote'; }
|
||||
pre.src-awk:before { content: 'Awk'; }
|
||||
pre.src-authinfo::before { content: 'Authinfo'; }
|
||||
pre.src-C:before { content: 'C'; }
|
||||
/* pre.src-C++ doesn't work in CSS */
|
||||
pre.src-clojure:before { content: 'Clojure'; }
|
||||
pre.src-css:before { content: 'CSS'; }
|
||||
pre.src-D:before { content: 'D'; }
|
||||
pre.src-ditaa:before { content: 'ditaa'; }
|
||||
pre.src-dot:before { content: 'Graphviz'; }
|
||||
pre.src-calc:before { content: 'Emacs Calc'; }
|
||||
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
||||
pre.src-fortran:before { content: 'Fortran'; }
|
||||
pre.src-gnuplot:before { content: 'gnuplot'; }
|
||||
pre.src-haskell:before { content: 'Haskell'; }
|
||||
pre.src-hledger:before { content: 'hledger'; }
|
||||
pre.src-java:before { content: 'Java'; }
|
||||
pre.src-js:before { content: 'Javascript'; }
|
||||
pre.src-latex:before { content: 'LaTeX'; }
|
||||
pre.src-ledger:before { content: 'Ledger'; }
|
||||
pre.src-lisp:before { content: 'Lisp'; }
|
||||
pre.src-lilypond:before { content: 'Lilypond'; }
|
||||
pre.src-lua:before { content: 'Lua'; }
|
||||
pre.src-matlab:before { content: 'MATLAB'; }
|
||||
pre.src-mscgen:before { content: 'Mscgen'; }
|
||||
pre.src-ocaml:before { content: 'Objective Caml'; }
|
||||
pre.src-octave:before { content: 'Octave'; }
|
||||
pre.src-org:before { content: 'Org mode'; }
|
||||
pre.src-oz:before { content: 'OZ'; }
|
||||
pre.src-plantuml:before { content: 'Plantuml'; }
|
||||
pre.src-processing:before { content: 'Processing.js'; }
|
||||
pre.src-python:before { content: 'Python'; }
|
||||
pre.src-R:before { content: 'R'; }
|
||||
pre.src-ruby:before { content: 'Ruby'; }
|
||||
pre.src-sass:before { content: 'Sass'; }
|
||||
pre.src-scheme:before { content: 'Scheme'; }
|
||||
pre.src-screen:before { content: 'Gnu Screen'; }
|
||||
pre.src-sed:before { content: 'Sed'; }
|
||||
pre.src-sh:before { content: 'shell'; }
|
||||
pre.src-sql:before { content: 'SQL'; }
|
||||
pre.src-sqlite:before { content: 'SQLite'; }
|
||||
/* additional languages in org.el's org-babel-load-languages alist */
|
||||
pre.src-forth:before { content: 'Forth'; }
|
||||
pre.src-io:before { content: 'IO'; }
|
||||
pre.src-J:before { content: 'J'; }
|
||||
pre.src-makefile:before { content: 'Makefile'; }
|
||||
pre.src-maxima:before { content: 'Maxima'; }
|
||||
pre.src-perl:before { content: 'Perl'; }
|
||||
pre.src-picolisp:before { content: 'Pico Lisp'; }
|
||||
pre.src-scala:before { content: 'Scala'; }
|
||||
pre.src-shell:before { content: 'Shell Script'; }
|
||||
pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
|
||||
/* additional language identifiers per "defun org-babel-execute"
|
||||
in ob-*.el */
|
||||
pre.src-cpp:before { content: 'C++'; }
|
||||
pre.src-abc:before { content: 'ABC'; }
|
||||
pre.src-coq:before { content: 'Coq'; }
|
||||
pre.src-groovy:before { content: 'Groovy'; }
|
||||
/* additional language identifiers from org-babel-shell-names in
|
||||
ob-shell.el: ob-shell is the only babel language using a lambda to put
|
||||
the execution function name together. */
|
||||
pre.src-bash:before { content: 'bash'; }
|
||||
pre.src-csh:before { content: 'csh'; }
|
||||
pre.src-ash:before { content: 'ash'; }
|
||||
pre.src-dash:before { content: 'dash'; }
|
||||
pre.src-ksh:before { content: 'ksh'; }
|
||||
pre.src-mksh:before { content: 'mksh'; }
|
||||
pre.src-posh:before { content: 'posh'; }
|
||||
/* Additional Emacs modes also supported by the LaTeX listings package */
|
||||
pre.src-ada:before { content: 'Ada'; }
|
||||
pre.src-asm:before { content: 'Assembler'; }
|
||||
pre.src-caml:before { content: 'Caml'; }
|
||||
pre.src-delphi:before { content: 'Delphi'; }
|
||||
pre.src-html:before { content: 'HTML'; }
|
||||
pre.src-idl:before { content: 'IDL'; }
|
||||
pre.src-mercury:before { content: 'Mercury'; }
|
||||
pre.src-metapost:before { content: 'MetaPost'; }
|
||||
pre.src-modula-2:before { content: 'Modula-2'; }
|
||||
pre.src-pascal:before { content: 'Pascal'; }
|
||||
pre.src-ps:before { content: 'PostScript'; }
|
||||
pre.src-prolog:before { content: 'Prolog'; }
|
||||
pre.src-simula:before { content: 'Simula'; }
|
||||
pre.src-tcl:before { content: 'tcl'; }
|
||||
pre.src-tex:before { content: 'TeX'; }
|
||||
pre.src-plain-tex:before { content: 'Plain TeX'; }
|
||||
pre.src-verilog:before { content: 'Verilog'; }
|
||||
pre.src-vhdl:before { content: 'VHDL'; }
|
||||
pre.src-xml:before { content: 'XML'; }
|
||||
pre.src-nxml:before { content: 'XML'; }
|
||||
/* add a generic configuration mode; LaTeX export needs an additional
|
||||
(add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
|
||||
pre.src-conf:before { content: 'Configuration File'; }
|
||||
|
||||
table { border-collapse:collapse; }
|
||||
caption.t-above { caption-side: top; }
|
||||
caption.t-bottom { caption-side: bottom; }
|
||||
td, th { vertical-align:top; }
|
||||
th.org-right { text-align: center; }
|
||||
th.org-left { text-align: center; }
|
||||
th.org-center { text-align: center; }
|
||||
td.org-right { text-align: right; }
|
||||
td.org-left { text-align: left; }
|
||||
td.org-center { text-align: center; }
|
||||
dt { font-weight: bold; }
|
||||
.footpara { display: inline; }
|
||||
.footdef { margin-bottom: 1em; }
|
||||
.figure { padding: 1em; }
|
||||
.figure p { text-align: center; }
|
||||
.equation-container {
|
||||
display: table;
|
||||
text-align: center;
|
||||
width: 100%;
|
||||
}
|
||||
.equation {
|
||||
vertical-align: middle;
|
||||
}
|
||||
.equation-label {
|
||||
display: table-cell;
|
||||
text-align: right;
|
||||
vertical-align: middle;
|
||||
}
|
||||
.inlinetask {
|
||||
padding: 10px;
|
||||
border: 2px solid gray;
|
||||
margin: 10px;
|
||||
background: #ffffcc;
|
||||
}
|
||||
#org-div-home-and-up
|
||||
{ text-align: right; font-size: 70%; white-space: nowrap; }
|
||||
textarea { overflow-x: auto; }
|
||||
.linenr { font-size: smaller }
|
||||
.code-highlighted { background-color: #ffff00; }
|
||||
.org-info-js_info-navigation { border-style: none; }
|
||||
#org-info-js_console-label
|
||||
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
|
||||
.org-info-js_search-highlight
|
||||
{ background-color: #ffff00; color: #000000; font-weight: bold; }
|
||||
.org-svg { }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div id="content" class="content">
|
||||
<div id="table-of-contents" role="doc-toc">
|
||||
<h2>Table of Contents</h2>
|
||||
<div id="text-table-of-contents" role="doc-toc">
|
||||
<ul>
|
||||
<li><a href="#org490606f">1. Evaluation</a>
|
||||
<ul>
|
||||
<li><a href="#org2f83090">1.1. Expirement setup</a>
|
||||
<ul>
|
||||
<li><a href="#org0d440d4">1.1.1. Performance counters used</a></li>
|
||||
<li><a href="#org9cacc1c">1.1.2. Benchmarks</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a href="#orgcc0820e">1.2. Results</a></li>
|
||||
<li><a href="#org1d8ebaa">1.3. Usability</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div id="outline-container-org490606f" class="outline-2">
|
||||
<h2 id="org490606f"><span class="section-number-2">1.</span> Evaluation</h2>
|
||||
<div class="outline-text-2" id="text-1">
|
||||
<p>
|
||||
We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
|
||||
the default memory allocator for CHERIBSD(, ), to assess the performance improvements
|
||||
enabled by a CHERI-based huge page-aware allocator. Specifically, we evaluated
|
||||
the reduction in TLB misses and its impact on overall
|
||||
performance metrics, such as wall clock runtime.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
To comprehensively analyze the proposed allocator, we categorized benchmarks into
|
||||
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
|
||||
C programs designed to target specific allocator patterns, enabling us to evaluate
|
||||
detailed aspects of the allocator's behavior. Macro benchmarks, on the other hand,
|
||||
encompass larger, real-world C programs, allowing us to assess the allocator's
|
||||
performance in more practical, real-world scenarios.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The experiment setup details the software stack used for evaluation. It includes
|
||||
the specific configurations, compiler options, and system environment tailored
|
||||
to benchmark the proposed allocator. This ensures consistency and repeatability
|
||||
in our results, providing a solid foundation for meaningful comparisons.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
We further elaborated on the two classes of benchmarks executed. Micro benchmarks
|
||||
focused on particular allocation and deallocation patterns, such as sequential and
|
||||
random memory accesses, to stress-test the allocator under controlled conditions.
|
||||
Macro benchmarks involved real-world applications, offering insights into how
|
||||
the allocator performs with complex memory allocation demands, large datasets,
|
||||
and varying execution contexts.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The results section presents the outcomes of our benchmarks, highlighting key metrics
|
||||
such as TLB miss rates, memory usage, and runtime performance. We observed that the
|
||||
proposed allocator demonstrated significant improvements in reducing TLB misses,
|
||||
leading to noticeable enhancements in runtime efficiency for both micro and macro
|
||||
benchmarks. The behavior of specific allocation patterns and their impact on memory
|
||||
performance is detailed, providing a nuanced understanding of the allocator's effectiveness.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Based on the evaluated results, the usability of the proposed allocator shows promise
|
||||
for applications requiring optimized memory management and reduced overhead from TLB misses.
|
||||
However, limitations were also identified, such as scenarios where the allocator's performance
|
||||
gains were marginal or where it introduced additional complexity in memory management. These
|
||||
limitations provide a roadmap for future optimizations and refinements of the allocator design.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org2f83090" class="outline-3">
|
||||
<h3 id="org2f83090"><span class="section-number-3">1.1.</span> Expirement setup</h3>
|
||||
<div class="outline-text-3" id="text-1-1">
|
||||
<p>
|
||||
The CHERI Morello board was used to evaluate the proposed memory allocator.
|
||||
Morello implements the ARM A76 with enhanced server-class memory, featuring a
|
||||
quad-core ARM CPU with capability extensions. The L1 and L2 caches were modified
|
||||
to proliferate the capability bit, ensuring compatibility with CHERI's capability-based
|
||||
memory model. When compiling the C programs for benchmarking, the Benchmark ABI was
|
||||
used as recommended by the CHERI community. This compilation mode was enabled using
|
||||
the Clang compiler.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The Benchmark ABI was specifically designed because the Morello branch predictor
|
||||
was not expanded to predict bounds. Consequently, a capability-based jump introduces
|
||||
stalls in later PCC-dependent instructions until bounds are established. This issue
|
||||
is particularly significant during dynamically linked calls and returns between
|
||||
libraries, where bounds are changed to cover the called or returned-to library.
|
||||
Such stalls can negatively affect performance, making the Benchmark ABI an essential
|
||||
consideration for this evaluation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Each C program was executed using two different memory allocators. The first was
|
||||
the modified C allocator, imported as a header file. This approach was necessary
|
||||
because the Benchmark ABI shared object file exhibited unexpected behavior,
|
||||
failing to overwrite the C program at runtime with the intended malloc functions.
|
||||
The second allocator was the standard OS memory allocator, which, in the case of
|
||||
CHERIBSD, is Jemalloc.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Performance measurements were carried out using ARM performance counters to
|
||||
ensure accurate evaluation. These counters provided detailed metrics, allowing
|
||||
us to compare the performance of the two allocators and assess the impact of
|
||||
the proposed changes.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org0d440d4" class="outline-4">
|
||||
<h4 id="org0d440d4"><span class="section-number-4">1.1.1.</span> Performance counters used</h4>
|
||||
<div class="outline-text-4" id="text-1-1-1">
|
||||
<!-- This HTML table template is generated by emacs 29.1 -->
|
||||
<table border="1">
|
||||
<tr>
|
||||
<td align="left" valign="top">
|
||||
Performance counter
|
||||
</td>
|
||||
<td align="left" valign="top">
|
||||
Description
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="left" valign="top">
|
||||
Wall clock <br />
|
||||
<br />
|
||||
<br />
|
||||
(p/l1d_tlb_rd) L1 data TLB reads <br />
|
||||
<br />
|
||||
(p/l2d_tlb_rd) L2 data TLB reads <br />
|
||||
<br />
|
||||
(p/l1d_tlb_refill) L1 data TLB refills <br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
(p/cpu_cycles) CPU cycles <br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
(p/dtlb_walk) Data TLB walks <br />
|
||||
<br />
|
||||
<br />
|
||||
(p/ll_cache_miss_rd) Last level cache miss reads <br />
|
||||
<br />
|
||||
<br />
|
||||
|
||||
</td>
|
||||
<td align="left" valign="top">
|
||||
The actual time taken from the start of a <br />
|
||||
computer program to the end. <br />
|
||||
<br />
|
||||
Level 1 data TLB access, read <br />
|
||||
<br />
|
||||
Level 2 data TLB access, read <br />
|
||||
<br />
|
||||
Level 1 data TLB refill. <br />
|
||||
The Level 1 data TLB refill <br />
|
||||
counter tracks each access to <br />
|
||||
the L1D_TLB that results <br />
|
||||
in a refill of the Level 1 data <br />
|
||||
or unified TLB. This includes any <br />
|
||||
access that requires a memory lookup <br />
|
||||
due to a translation table walk <br />
|
||||
or accessing another level of TLB cache. <br />
|
||||
<br />
|
||||
The CPU CYCLES counter increases with <br />
|
||||
every clock cycle. However, it can be <br />
|
||||
affected by changes in clock frequency, <br />
|
||||
such as when WFI (Wait for Interrupt) <br />
|
||||
or WFE (Wait for Event) <br />
|
||||
instructions pause the clock. <br />
|
||||
<br />
|
||||
Data TLB access with at least <br />
|
||||
one translation table walk. <br />
|
||||
<br />
|
||||
Last level cache miss, read <br />
|
||||
(This refers to every miss in the <br />
|
||||
Last level cache that occurs <br />
|
||||
during a memory read operation.)
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org9cacc1c" class="outline-4">
|
||||
<h4 id="org9cacc1c"><span class="section-number-4">1.1.2.</span> Benchmarks</h4>
|
||||
<div class="outline-text-4" id="text-1-1-2">
|
||||
<p>
|
||||
The benchmarks are classified into 2 classes:
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<ol class="org-ol">
|
||||
<li><a id="orge18d7e4"></a>Micro benchmark<br />
|
||||
<div class="outline-text-5" id="text-1-1-2-1">
|
||||
<ul class="org-ul">
|
||||
<li>GLIBC: The Glibc benchmark evaluates the performance of
|
||||
malloc and free functions in single-threaded, multi-threaded,
|
||||
and emulated multi-threading scenarios using various block sizes and
|
||||
allocation patterns. It simulates real-world memory usage by partially
|
||||
deallocating blocks in FIFO order and fully deallocating them in LIFO order.
|
||||
Results are gathered across configurations to analyze performance variations.</li>
|
||||
<li>MemAccess: This benchmark by Alex Bordei evaluates the performance impact of
|
||||
memory access patterns by constructing and traversing a doubly
|
||||
linked list with varying working set sizes. It supports sequential or
|
||||
randomized structures, optional node operations, and multithreaded
|
||||
traversal using pthreads. The program dynamically allocates memory and systematically
|
||||
doubles the working set size to analyze memory hierarchy behavior.</li>
|
||||
</ul>
|
||||
</div>
|
||||
</li>
|
||||
|
||||
<li><a id="org697b307"></a>Macro runs<br />
|
||||
<div class="outline-text-5" id="text-1-1-2-2">
|
||||
<ul class="org-ul">
|
||||
<li>Kmeans: Kmeans implements a parallelized K-means clustering algorithm that
|
||||
assigns data points to clusters based on proximity to centroids,
|
||||
iteratively updating them until convergence. The computation is
|
||||
distributed across threads using the pthread library, dynamically
|
||||
assigning tasks to optimize performance. Parameters like data size
|
||||
and clusters are configurable, and the program ensures efficient
|
||||
memory management and synchronization.</li>
|
||||
<li>Richards: Richards is a task scheduling benchmark that simulates a
|
||||
multitasking environment with tasks of varying types and priorities,
|
||||
communicating through queued packets. The schedule function manages
|
||||
task execution based on state and priority, tracking processed packets
|
||||
and held tasks for performance evaluation. Configurable iterations and
|
||||
timing help measure system performance and ensure correctness.</li>
|
||||
</ul>
|
||||
</div>
|
||||
</li>
|
||||
</ol>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-orgcc0820e" class="outline-3">
|
||||
<h3 id="orgcc0820e"><span class="section-number-3">1.2.</span> Results</h3>
|
||||
<div class="outline-text-3" id="text-1-2">
|
||||
|
||||
<div id="org0a8604a" class="figure">
|
||||
<p><img src="./diagrams/allbenchmarks.png" alt="allbenchmarks.png" align="right" />
|
||||
</p>
|
||||
</div>
|
||||
|
||||
|
||||
<div id="org7ada87f" class="figure">
|
||||
<p><img src="./diagrams/kmeans.png" alt="kmeans.png" align="right" />
|
||||
</p>
|
||||
</div>
|
||||
|
||||
|
||||
<div id="orgedd36f2" class="figure">
|
||||
<p><img src="./diagrams/glibc.png" alt="glibc.png" align="right" />
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="outline-container-org1d8ebaa" class="outline-3">
|
||||
<h3 id="org1d8ebaa"><span class="section-number-3">1.3.</span> Usability</h3>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div id="postamble" class="status">
|
||||
<p class="author">Author: Akilan</p>
|
||||
<p class="date">Created: 2025-01-12 Sun 17:26</p>
|
||||
<p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
@@ -196,12 +196,113 @@ The benchmarks are classified into 2 classes:
|
||||
#+ATTR_ORG: :align center
|
||||
[[./diagrams/allbenchmarks.png]]
|
||||
|
||||
#+BEGIN_COMMENT
|
||||
The graph above refers to the precentage difference between the modified
|
||||
memory allocator against the default system memory allocator which is
|
||||
Jemalloc. Since FAT pointer memory allocator is desgined to allocate
|
||||
with huge pages the results in graph above has the appripirate
|
||||
expected corresponding behavoir. It is noticable the data
|
||||
TLB walk, L2 data TLB reads and refill are consistently
|
||||
90% lesser than the default memory allocator accross
|
||||
the benchmarks listed on the graph above. This is
|
||||
because of a single huge page entry at the l1 TLB
|
||||
layer. This means most address translations hit L1
|
||||
TLB without having to walk through the heirarchy of
|
||||
TLB translations.
|
||||
|
||||
The micro benchmarks are designed for more memory reads
|
||||
and shows on average a 50% reduction on wallclock runtimes.
|
||||
The macro benchmarks on the other hand which are larger
|
||||
classes of C programs have minimal differences in wall
|
||||
clock run times.
|
||||
#+END_COMMENT
|
||||
|
||||
|
||||
The graph above 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
|
||||
of its capability to handle memory more efficiently by leveraging huge pages.
|
||||
|
||||
A particularly striking observation is the significant reduction in data TLB walks,
|
||||
L2 data TLB reads, and TLB refills—consistently showing a 90% decrease across all
|
||||
benchmarks compared to Jemalloc. This improvement is due to the modified allocator's
|
||||
use of a single huge page entry at the L1 TLB layer. By enabling most address translations
|
||||
to be resolved directly at the L1 TLB, the need to walk through the deeper TLB hierarchy is
|
||||
largely eliminated. This reduction in translation overhead is a key factor in the allocator's
|
||||
superior performance for certain types of workloads.
|
||||
|
||||
The micro benchmarks, which are crafted to emphasize memory read operations, highlight the
|
||||
allocator's strengths. These tests simulate frequent and intensive memory access patterns,
|
||||
where the reduction in TLB misses directly translates into measurable performance gains.
|
||||
On average, the FAT pointer allocator achieves a 50% reduction in wall clock runtimes for
|
||||
these workloads, underscoring its ability to optimize high-throughput memory operations.
|
||||
|
||||
On the other hand, macro benchmarks, which represent larger and more complex real-world applications,
|
||||
exhibit minimal differences in wall clock runtimes when using the FAT pointer allocator.
|
||||
This outcome is expected, as macro benchmarks typically involve a broader range of operations
|
||||
beyond memory allocation, diluting the impact of the allocator's optimizations. Additionally,
|
||||
the benefits of huge pages may be less pronounced for these workloads, as they are often
|
||||
bottlenecked by factors such as computation or I/O rather than memory translation overhead.
|
||||
|
||||
#+ATTR_HTML: :align right
|
||||
#+ATTR_ORG: :align center
|
||||
[[./diagrams/kmeans.png]]
|
||||
|
||||
#+BEGIN_COMMENT
|
||||
The kmeans was executed with various cluster sizes to see
|
||||
the percentage difference against the baseline allocator as
|
||||
the size of the workload increases. It can be noted that
|
||||
the percentage difference stays the same except during
|
||||
the cluster size of 2000.
|
||||
#+END_COMMENT
|
||||
The K-means algorithm was executed with varying cluster sizes to evaluate the performance difference
|
||||
between the FAT pointer allocator and the baseline allocator as the workload scales. This analysis
|
||||
aimed to understand how the allocator's optimizations, particularly its ability to manage memory
|
||||
more efficiently with huge pages, impact performance under different workload conditions.
|
||||
|
||||
For most cluster sizes tested, the percentage difference in performance remained relatively
|
||||
consistent. This indicates that the allocator's efficiency scales predictably with increasing
|
||||
workload sizes, suggesting a stable and uniform benefit across different configurations. The
|
||||
consistent performance gain is likely due to the allocator's ability to minimize TLB misses
|
||||
and efficiently manage memory allocations for the centroid and data point structures used in
|
||||
the K-means algorithm.
|
||||
|
||||
However, an anomaly was observed at a cluster size of 2000, where the percentage difference
|
||||
deviated significantly from the trend. This irregularity could be attributed to several factors.
|
||||
At this cluster size, the memory access patterns and allocation behavior may align in a way that
|
||||
temporarily offsets the advantages of the FAT pointer allocator. For example, the memory layout
|
||||
might interact with system-level caching mechanisms or TLB behavior differently, leading to an
|
||||
unexpected change in performance. Additionally, the increased complexity of managing a higher
|
||||
number of clusters might introduce computational overhead that overshadows the memory allocator's
|
||||
optimizations.
|
||||
|
||||
This observation highlights the importance of testing across a range of workload sizes and
|
||||
configurations to uncover edge cases or specific scenarios where performance deviates from the
|
||||
expected pattern. Understanding these anomalies can provide insights into the allocator's
|
||||
behavior and guide future improvements to address such outliers. Despite the deviation at a
|
||||
cluster size of 2000, the overall results reaffirm the allocator's capability to maintain
|
||||
consistent performance benefits across most scenarios.
|
||||
|
||||
#+BEGIN_COMMENT
|
||||
#+ATTR_HTML: :align right
|
||||
#+ATTR_ORG: :align center
|
||||
[[./diagrams/glibc.png]]
|
||||
|
||||
#+END_COMMENT
|
||||
** Usability
|
||||
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,
|
||||
and TLB refills compared to Jemalloc. These improvements lead to noticeable performance
|
||||
gains, especially in micro benchmarks, where the allocator reduces wall clock runtimes
|
||||
by an average of 50%.
|
||||
|
||||
The allocator integrates seamlessly into memory-intensive workloads, as evidenced by its
|
||||
consistent performance across varying cluster sizes in the K-means benchmark, with only
|
||||
minor anomalies observed under specific conditions. These outliers provide valuable
|
||||
insights into the allocator's interaction with system-level caching and memory translation mechanisms.
|
||||
|
||||
While the allocator excels in scenarios emphasizing high memory throughput, its impact on
|
||||
macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
|
||||
applications with frequent and intensive memory operations rather than those constrained by
|
||||
computation or I/O bottlenecks.
|
||||
Binary file not shown.
@@ -1,4 +1,4 @@
|
||||
% Created 2025-01-09 Thu 22:53
|
||||
% Created 2025-01-14 Tue 14:03
|
||||
% Intended LaTeX compiler: pdflatex
|
||||
\documentclass[11pt]{article}
|
||||
\usepackage[utf8]{inputenc}
|
||||
@@ -27,7 +27,7 @@
|
||||
\tableofcontents
|
||||
|
||||
\section{Evaluation}
|
||||
\label{sec:org02aba25}
|
||||
\label{sec:orgbbe52ec}
|
||||
|
||||
We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
|
||||
the default memory allocator for 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:org9bf5b27}
|
||||
\label{sec:org0672379}
|
||||
|
||||
The CHERI 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.
|
||||
|
||||
\subsubsection{Performance counters used}
|
||||
\label{sec:org294979c}
|
||||
\label{sec:org9f2d2f7}
|
||||
|
||||
\begin{center}
|
||||
\begin{tabular}{|l|l|}
|
||||
@@ -142,12 +142,12 @@ Wall clock & The actual time taken from the start of a \\
|
||||
\end{center}
|
||||
|
||||
\subsubsection{Benchmarks}
|
||||
\label{sec:orgddacffd}
|
||||
\label{sec:org91388b2}
|
||||
The benchmarks are classified into 2 classes:
|
||||
|
||||
\begin{enumerate}
|
||||
\item Micro benchmark
|
||||
\label{sec:orgb329a4e}
|
||||
\label{sec:orgf10bbbd}
|
||||
\begin{itemize}
|
||||
\item GLIBC: The Glibc benchmark evaluates the performance of
|
||||
malloc and free functions in single-threaded, multi-threaded,
|
||||
@@ -164,7 +164,7 @@ doubles the working set size to analyze memory hierarchy behavior.
|
||||
\end{itemize}
|
||||
|
||||
\item Macro runs
|
||||
\label{sec:orga786fd0}
|
||||
\label{sec:orgc073fbd}
|
||||
\begin{itemize}
|
||||
\item Kmeans: Kmeans implements a parallelized K-means clustering algorithm that
|
||||
assigns data points to clusters based on proximity to centroids,
|
||||
@@ -183,19 +183,86 @@ timing help measure system performance and ensure correctness.
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Results}
|
||||
\label{sec:org4bdc0d9}
|
||||
\label{sec:org306bf15}
|
||||
\begin{center}
|
||||
\includegraphics[width=.9\linewidth]{./diagrams/allbenchmarks.png}
|
||||
\end{center}
|
||||
|
||||
|
||||
The graph above 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
|
||||
of its capability to handle memory more efficiently by leveraging huge pages.
|
||||
|
||||
A particularly striking observation is the significant reduction in data TLB walks,
|
||||
L2 data TLB reads, and TLB refills—consistently showing a 90\% decrease across all
|
||||
benchmarks compared to Jemalloc. This improvement is due to the modified allocator's
|
||||
use of a single huge page entry at the L1 TLB layer. By enabling most address translations
|
||||
to be resolved directly at the L1 TLB, the need to walk through the deeper TLB hierarchy is
|
||||
largely eliminated. This reduction in translation overhead is a key factor in the allocator's
|
||||
superior performance for certain types of workloads.
|
||||
|
||||
The micro benchmarks, which are crafted to emphasize memory read operations, highlight the
|
||||
allocator's strengths. These tests simulate frequent and intensive memory access patterns,
|
||||
where the reduction in TLB misses directly translates into measurable performance gains.
|
||||
On average, the FAT pointer allocator achieves a 50\% reduction in wall clock runtimes for
|
||||
these workloads, underscoring its ability to optimize high-throughput memory operations.
|
||||
|
||||
On the other hand, macro benchmarks, which represent larger and more complex real-world applications,
|
||||
exhibit minimal differences in wall clock runtimes when using the FAT pointer allocator.
|
||||
This outcome is expected, as macro benchmarks typically involve a broader range of operations
|
||||
beyond memory allocation, diluting the impact of the allocator's optimizations. Additionally,
|
||||
the benefits of huge pages may be less pronounced for these workloads, as they are often
|
||||
bottlenecked by factors such as computation or I/O rather than memory translation overhead.
|
||||
|
||||
\begin{center}
|
||||
\includegraphics[width=.9\linewidth]{./diagrams/kmeans.png}
|
||||
\end{center}
|
||||
|
||||
\begin{center}
|
||||
\includegraphics[width=.9\linewidth]{./diagrams/glibc.png}
|
||||
\end{center}
|
||||
The K-means algorithm was executed with varying cluster sizes to evaluate the performance difference
|
||||
between the FAT pointer allocator and the baseline allocator as the workload scales. This analysis
|
||||
aimed to understand how the allocator's optimizations, particularly its ability to manage memory
|
||||
more efficiently with huge pages, impact performance under different workload conditions.
|
||||
|
||||
For most cluster sizes tested, the percentage difference in performance remained relatively
|
||||
consistent. This indicates that the allocator's efficiency scales predictably with increasing
|
||||
workload sizes, suggesting a stable and uniform benefit across different configurations. The
|
||||
consistent performance gain is likely due to the allocator's ability to minimize TLB misses
|
||||
and efficiently manage memory allocations for the centroid and data point structures used in
|
||||
the K-means algorithm.
|
||||
|
||||
However, an anomaly was observed at a cluster size of 2000, where the percentage difference
|
||||
deviated significantly from the trend. This irregularity could be attributed to several factors.
|
||||
At this cluster size, the memory access patterns and allocation behavior may align in a way that
|
||||
temporarily offsets the advantages of the FAT pointer allocator. For example, the memory layout
|
||||
might interact with system-level caching mechanisms or TLB behavior differently, leading to an
|
||||
unexpected change in performance. Additionally, the increased complexity of managing a higher
|
||||
number of clusters might introduce computational overhead that overshadows the memory allocator's
|
||||
optimizations.
|
||||
|
||||
This observation highlights the importance of testing across a range of workload sizes and
|
||||
configurations to uncover edge cases or specific scenarios where performance deviates from the
|
||||
expected pattern. Understanding these anomalies can provide insights into the allocator's
|
||||
behavior and guide future improvements to address such outliers. Despite the deviation at a
|
||||
cluster size of 2000, the overall results reaffirm the allocator's capability to maintain
|
||||
consistent performance benefits across most scenarios.
|
||||
\subsection{Usability}
|
||||
\label{sec:org3b91bbd}
|
||||
\label{sec:orgb4de289}
|
||||
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,
|
||||
and TLB refills compared to Jemalloc. These improvements lead to noticeable performance
|
||||
gains, especially in micro benchmarks, where the allocator reduces wall clock runtimes
|
||||
by an average of 50\%.
|
||||
|
||||
The allocator integrates seamlessly into memory-intensive workloads, as evidenced by its
|
||||
consistent performance across varying cluster sizes in the K-means benchmark, with only
|
||||
minor anomalies observed under specific conditions. These outliers provide valuable
|
||||
insights into the allocator's interaction with system-level caching and memory translation mechanisms.
|
||||
|
||||
While the allocator excels in scenarios emphasizing high memory throughput, its impact on
|
||||
macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
|
||||
applications with frequent and intensive memory operations rather than those constrained by
|
||||
computation or I/O bottlenecks.
|
||||
\end{document}
|
||||
Reference in New Issue
Block a user