159 lines
9.4 KiB
TeX
159 lines
9.4 KiB
TeX
% Created 2025-06-18 Wed 19:47
|
||
% 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 30.1 (Org mode 9.7.11)},
|
||
pdflang={English}}
|
||
\begin{document}
|
||
|
||
\tableofcontents
|
||
|
||
\section{FAT Allocator without the TLB}
|
||
\label{sec:orga3b6b50}
|
||
|
||
\subsection{Abstract}
|
||
\label{sec:org5961619}
|
||
This document explores an extension of the FAT allocator approach to memory management in RISC-V Toooba\cite{rugg_2022}.
|
||
CHERI introduces a fine-grained memory protection mechanism by embedding bounds and permissions directly
|
||
within pointers. Leveraging this model, we propose a system in which offsets are stored within the pointer itself, enabling
|
||
direct memory access without reliance on traditional address translation mechanisms such as the TLB. This method
|
||
facilitates the design of a block-based memory allocator within physically contiguous memory. The sections expanded below
|
||
are the technique expected to be used and the evaluation criteria for the following experiment.
|
||
\subsection{Research questions}
|
||
\label{sec:orge1b3555}
|
||
\begin{enumerate}
|
||
\item How can embedding offsets within a FAT pointer (i.e CHERI pointer) improve memory accesses for a block-based allocator for the RISC-V CHERI modified Toooba architecture ?
|
||
\item To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency ?
|
||
\end{enumerate}
|
||
\subsection{Proposed approach}
|
||
\label{sec:orga716280}
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=300px]{./diagram/MainOverview.png}
|
||
\caption{\label{fig:orgf01f491}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
|
||
\end{figure}
|
||
|
||
FAT-Pointers based range addresses, combined with the capabilities of the CHERI architecture, introduce
|
||
bypassing the TLB hierarchy by incorporating additional metadata with memory pointers.
|
||
This enhanced architecture utilises concepts such as FlexPointer\cite{FlexPointer}, Range Memory Mapping (RMM)\cite{rmm} to manage memory as customised sizes rather than groups
|
||
of fixed page sizes. Range addresses play a pivotal role within this framework, defining memory regions bounded by a starting address
|
||
(Upper) and an ending address (Lower). These range addresses are encoded within FAT-pointers, allowing for precise control
|
||
over memory regions. The functionality of ranges encompasses several key aspects:
|
||
|
||
\begin{itemize}
|
||
\item Creation of Physically Contiguous Memory Ranges.
|
||
\item Encoding Ranges as Bounds to the Pointer.
|
||
\item Instrumenting Block-Based Allocators with the FAT Pointer.
|
||
\end{itemize}
|
||
|
||
In figure \ref{fig:orgf01f491}, the green-highlighted section marks the unused space between the 48th and 64th bits
|
||
within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata,
|
||
potentially enhancing the capabilities of the memory management system.
|
||
|
||
\begin{figure}[htbp]
|
||
\centering
|
||
\includegraphics[width=500px]{./diagram/Toooba-codesnippet.png}
|
||
\caption{\label{fig:org8363643}Toooba processor with pseudo code change to bypass DataTLB.}
|
||
\end{figure}
|
||
\subsubsection{Implementation}
|
||
\label{sec:org4e24323}
|
||
The figure \ref{fig:org8363643} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture.
|
||
On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that we will need to do to the
|
||
memory pipeline in order to bypass the use of the Data TLB and instead utilise the offset from the pointer. The primary focus will be
|
||
on the memory pipeline.\\
|
||
|
||
\begin{itemize}
|
||
\item Each pipeline will contain a reservation station that will accept relevant instructions from the rename stage and buffer them until their register dependencies have been resolved.\\
|
||
|
||
\item Following this, the dispatch stage will update the necessary state in the reservation station and forward the instruction to the rest of the pipeline.\\
|
||
|
||
\item The register read stage will then latch the required values from the physical register file, or from forwarding paths if those values are already available.\\
|
||
|
||
\item The execute stage will perform the specified operation. In the case of the memory pipeline, it will additionally calculate addresses by adding the immediate value to the read register where applicable, and will manage interactions with the Load/Store Queue.\\
|
||
|
||
\item Originally, the memory pipeline's execute stage also interacted with the Data TLB, but this will be replaced by a translation mechanism encoded in the offset, which will perform the necessary address translations.\\
|
||
|
||
\item The Load/Store Queue will continue to receive signals from various parts of the processor. A slot will be requested during the rename stage, and the memory pipeline’s finish stage will commit the access once all exceptions have been resolved.\\
|
||
|
||
\item Whereas this stage was previously triggered by a TLB response, it will now operate without walking the TLB hierarchy. Instead, the physical address will be computed directly by adding the offset to the virtual address in a single clock cycle, after which any exceptions will be handled appropriately.\\
|
||
\end{itemize}
|
||
|
||
Importantly, the finish stage will not require the actual memory access to have taken place for a load instruction, enabling the core
|
||
to support out-of-order execution. Memory responses will be processed asynchronously, potentially after the commit stage, with the
|
||
returned data written to the appropriate physical register. Generally, the memory pipeline will remain unchanged, except to support
|
||
the new access types, incorporate the Data TLB bypass mechanism, and include the necessary capability checks to ensure that accesses
|
||
are properly authorised.
|
||
\subsection{Proposed evaluation}
|
||
\label{sec:orgc0caeea}
|
||
The evaluation of the proposed FAT allocator implemented using CHERI-enhanced pointers on the RISC-V Toooba architecture
|
||
aims to assess both its performance characteristics and architectural implications, particularly in the context of removing
|
||
the Translation Lookaside Buffer (TLB) from the memory access pathway. The evaluation methodology is designed to address
|
||
the research questions with a focus on improvements in memory access and reductions in
|
||
latency for address translation.
|
||
\subsubsection{BlueSpec simulator}
|
||
\label{sec:org2206786}
|
||
To evaluate the proposed FAT pointer based memory management architecture, we plan to conduct simulations using the
|
||
Bluespec SystemVerilog (BSV)\cite{bsv} framework. Bluespec provides a cycle-accurate hardware simulation environment that
|
||
allows precise modelling of architectural behaviour, including custom memory pipelines, capability checking, and
|
||
physical address translation bypass mechanisms.
|
||
\subsubsection{Performance Metrics}
|
||
\label{sec:orgf6cbf89}
|
||
|
||
To quantify the performance benefits of the proposed system, the following metrics will be investigated:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{CPU clock cycles per memory access:}
|
||
This metric evaluates the computational overhead involved in memory access operations. A comparative analysis will
|
||
be conducted against conventional TLB-based systems with the hypothesis that the proposed architecture will exhibit
|
||
reduced cycle counts due to the elimination of virtual-to-physical address translation.
|
||
|
||
\item \textbf{Memory access latency:}
|
||
The latency associated with memory access will be measured under various workload conditions. By embedding offset
|
||
information directly within pointers and bypassing the TLB, the proposed approach is expected to achieve significantly
|
||
lower latency compared to traditional systems.
|
||
|
||
\item \textbf{Instruction path length:}
|
||
An analysis of the number of instructions executed during allocation, deallocation and memory access operations will be performed to
|
||
determine whether the additional logic required for handling FAT pointers introduces meaningful overhead.
|
||
\end{itemize}
|
||
\subsubsection{System Resource Utilisation}
|
||
\label{sec:org629ea18}
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Cache behaviour}
|
||
The proposed system's influence on cache performance will be assessed through performance counters, focusing on metrics such as cache
|
||
hit and miss rates. It is expected that physically contiguous allocations will result in improved spatial locality and cache efficiency.
|
||
|
||
\item \textbf{TLB miss rate (baseline comparison)}
|
||
Although the system does not utilise a TLB, comparative analysis will be performed with traditional TLB-based systems to quantify
|
||
the performance cost typically incurred through TLB misses, thereby contextualising the advantage of their removal.
|
||
\end{itemize}
|
||
\subsubsection{Benchmarking Against Baseline Architectures}
|
||
\label{sec:orgb71ca58}
|
||
|
||
A series of micro and macro benchmarks will be employed to compare the FAT allocator with traditional memory allocators that rely on virtual
|
||
memory and TLBs. Micro benchmarks will include fine-grained tests of memory operations, while macro benchmarks will involve application-level
|
||
scenarios such as numerical computing and dynamic data structure manipulation, providing a comprehensive assessment of system-level impact.
|
||
|
||
\bibliographystyle{IEEEtran}
|
||
\bibliography{FuturePlan.bib}
|
||
\end{document}
|