# Caching parameters for mcoxfile and mcoxflash

> As described in the Storage Stack Options, the eXtremeDB/rt Copy-On-Write (CoW) mechanism includes a page mapping layer that translates logical addresses to physical media locations. This mapping structure is itself persisted on the storage media to maintain consistency across sessions and system restarts.

> To improve runtime performance and minimize the overhead of frequent media lookups, both mcoxfile and mcoxflash storage modules implement an in-memory caching layer using a Translation Look-aside Buffer (TLB). The TLB stores recently accessed map entries, enabling faster resolution of logical-to-physical address translations.

> - For mcoxfile, each TLB cache entry occupies 8 bytes of RAM.
> - For mcoxflash, each entry requires 132 bytes, reflecting the additional metadata and flash-specific considerations.

> The size and behavior of this cache can be fine-tuned using dedicated configuration parameters, allowing developers to balance memory usage with access speed based on the needs of the target platform and application workload.

> mcoxfile:

>         db_params.tlb_cache_lines           = P_DB_TLB_CACHE_LINES;
>         db_params.tlb_cache_ways            = P_DB_TLB_CACHE_WAYS;

> mcoxflash:

>         db_params.meta_cache_lines          = P_DB_META_CACHE_LINES;
>         db_params.meta_cache_ways           = P_DB_META_CACHE_WAYS;

> Also, for mcoxflash there is a configuration parameter defining frequency of garbage collection for unmanaged flash performed by eXtremeDB/rt’s FTL.

>         db_params.flash_gc_ratio            = P_DB_FLASH_GC_RATIO;

> The Translation Lookaside Buffer (TLB) is a small, high-speed cache used to store recently accessed virtual-to-physical address mappings. Its purpose is to reduce the overhead of repeated page table lookups by keeping frequently used translations readily available in RAM.

> In eXtremeDB/rt, the TLB is organized into cache lines (*_cache_lines) and ways or positions (*_cache_ways). Each cache line contains multiple positions where address translation entries can be stored. The system uses an N-way set-associative placement strategy—meaning a given virtual address can be stored in one of several slots within a specific cache line.

> To look up an entry for address P, the system computes the cache line index using P mod L (where L is the number of lines). It then searches through the configured number of ways within that line to find a match.

> ### Configuration Recommendations

> - *_cache_ways:

>   Avoid setting this to 1 (which would result in direct-mapped caching, prone to collisions), but also don’t make it excessively large. A value of 4 to 8 typically provides a good balance between performance and memory usage.

> - *_cache_lines:

>   Set this based on available RAM and performance requirements. Larger values improve hit rates but consume more memory. This is the primary parameter to tune if you want to scale the cache for higher workloads.