11 KiB
FAT Allocator without the TLB
Abstract
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.
Research questions
- 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 ?
- To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency ?
Proposed approach
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:
- Creation of Physically Contiguous Memory Ranges.
- Encoding Ranges as Bounds to the Pointer.
- Instrumenting Block-Based Allocators with the FAT Pointer.
In Figure fig:RFPBRA, proposes a hybrid system that operates alongside the MMU and enables the conversion of virtual addresses to physical addresses without requiring a TLB lookup or a Page Table Entry (PTE) translation. To provide a basic overview, the red/orange line illustrates the standard translation path from a virtual to a physical address, while the green line represents our proposed approach. This method leverages CHERI capabilities to define memory ranges using bounds and to perform address translation directly at the pointer level, rather than traversing multiple TLB caches and/or accesing the page table. The diagram follows the SV39 addressing scheme.
The standard translation procedure
When a store, load or fetch instruction is issued, the virtual address, 39 bits in length, comprises several fields: the Virtual Page Number (VPN) fields 2 to 0, each 8 bits wide and an 11-bit offset. The VPN is first checked within the TLB hierarchy to determine whether a corresponding Physical Page Number (PPN) can be found. If it exists, the 11-bit offset from the virtual address is reused to construct the physical address, which can then be used to access the desired memory location. If the translation is not present in the TLB hierarchy, a page table walk is initiated by consulting the PTEs. A PTE can either reference another PTE or serve as a base PTE, as determined by its permission bits. For a 4 KB translation entry, this lookup may require up to three memory access cycles to complete the PTE translation, excluding any additional cycles incurred due to a TLB miss.
Our approach
We take advantage of the CHERI Capability 128 bit format and extend it by 16 more bits to store our custom offset. On translation we only use VPN2 and keep the other VPNs identical to the PPN. In the conversional scheme this would be only the case if we are allocating a giga page. In our case we just need a single VPN and PPN since we have use the bounds to dynamically control the size of a page and using the proposed 16 bit offset to add to the VPN to get the PPN. This means the entire translation can be done in single clock cycle.
Allocation approach
For practical reasons when calling malloc from a C program which calls mmap under the hood for mapping memory we wouldn't change much of calling kernel function calls such as pmap_store to create a PTE entry. But at hardware level we will extended 16 bits to store the offset for getting PPN2 to construct the physical address. If the 16 bits is set of we will program the TLB flush instruction (i.e Sfence.vma) to do nothing. This because we do not promote PTE entries to the TLB since they are not needed.
Implementation
The figure fig:CSTOOOBA 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.\\
- 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.\\
- Following this, the dispatch stage will update the necessary state in the reservation station and forward the instruction to the rest of the pipeline.\\
- 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.\\
- 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.\\
- 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.\\
- 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.\\
- 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.\\
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.
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.
BlueSpec simulator
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.
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 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.
- 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.
\bibliographystyle{IEEEtran} \bibliography{FuturePlan.bib}