110 lines
7.7 KiB
Org Mode
110 lines
7.7 KiB
Org Mode
* FAT Allocator without the TLB
|
||
|
||
** Abstract
|
||
This document explores an extension of the FAT allocator approach to memory management in RISC-V Toooba.
|
||
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.
|
||
|
||
** Research questions
|
||
1. 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 ?
|
||
2. To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency in a physically contiguous memory ?
|
||
|
||
** Proposed approach
|
||
#+attr_latex: :width 300px
|
||
#+CAPTION: FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.
|
||
#+NAME: fig:RFPBRA
|
||
[[./diagram/MainOverview.png]]
|
||
|
||
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, Range Memory Mapping (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:
|
||
|
||
- Creation of Physically Contiguous Memory Ranges.
|
||
- Encoding Ranges as Bounds to the Pointer.
|
||
- Instrumenting Block-Based Allocators with the FAT Pointer.
|
||
|
||
In figure 2.1, 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. Here we explore how this additional
|
||
metadata storage could be used to further optimise memory allocation.
|
||
|
||
#+attr_latex: :width 500px
|
||
#+CAPTION: Toooba processor with pseudo code change to bypass DataTLB.
|
||
#+NAME: fig:CSTOOOBA
|
||
[[./diagram/Toooba-codesnippet.png]]
|
||
|
||
*** Implementation
|
||
The figure 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 implementation highlights the modifications that will need to be made 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.
|
||
|
||
The structure of the memory pipeline will closely resemble that of the other pipelines. Both the dispatch and register read stages will carry out
|
||
the same functions. The execute stage will compute addresses by adding the immediate value to the read register where necessary, and it will handle
|
||
interactions with the Load/Store Queue. Originally, this stage also interacted with the Data TLB, but this will be replaced by a translation mechanism
|
||
encoded in the offset, which will perform the required address translations.
|
||
|
||
The Load/Store Queue will continue to receive signals from other parts of the processor. A slot will be requested in the rename stage, and the memory
|
||
pipeline’s finish stage will commit the access once all exceptions have been resolved. While this stage was previously triggered by a response from the
|
||
TLB, it will now be initiated without traversing the TLB hierarchy. Instead, the physical address will be obtained in a single clock cycle by directly
|
||
adding the offset to the virtual address, after which any exceptions will be managed.
|
||
|
||
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.
|
||
|
||
** Proposed evaluation
|
||
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 outlined in Section 1.2 with a focus on improvements in memory access efficiency and reductions in
|
||
latency and computational overhead.
|
||
|
||
*** BlueSpec simulator
|
||
To evaluate the proposed FAT pointer based memory management architecture, we conduct simulations using the
|
||
Bluespec SystemVerilog (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.
|
||
|
||
*** Performance Metrics
|
||
|
||
To quantify the performance benefits of the proposed system, the following metrics will be investigated:
|
||
|
||
- *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.
|
||
|
||
- *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.
|
||
|
||
- *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.
|
||
|
||
*** System Resource Utilisation
|
||
|
||
- *Cache behaviour*
|
||
The proposed system’s influence on cache performance will be assessed through profiling tools, 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.
|
||
|
||
- *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.
|
||
|
||
*** Benchmarking Against Baseline Architectures
|
||
|
||
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.
|
||
|