How to disable LFU admission filter?

[PhotonQuantum]

I have a specific scenario where I need to disable the LFU admission filter and use Moka as a simple LRU cache instead. However, I still want to use invalidate_entries_if and ttl features, so switching to another crate isn't an option. Do you have any suggestions on how I can achieve this?

My guess is that I could disable the LFU filter by returning false whenever should_enable_frequency_sketch gets called.

moka/src/sync_base/base_cache.rs

Line 1380 in 2e904db

fn should_enable_frequency_sketch(&self, counters: &EvictionCounters) -> bool {

Is this correct?

[tatsuya6502]

Hi.

My guess is that I could disable the LFU filter by returning false whenever should_enable_frequency_sketch gets called.

I will review the code later today, but I think you will need to do the followings:

1. As you said, change should_enable_frequency_sketch to return false.
2. Change admit to return AdmissionResult::Admitted { SmallVec::default() }.
   • Without changing it, admit will always return AdmissionResult::Rejected when the LFU filter is disabled.

moka/src/sync_base/base_cache.rs

Lines 1659 to 1664 in 2e904db

	fn admit(
	candidate: &EntrySizeAndFrequency,
	cache: &CacheStore<K, V, S>,
	deqs: &mut Deques<K>,
	freq: &FrequencySketch,
	) -> AdmissionResult<K> {

[tatsuya6502]

This seems an easy task for me. If you can wait for a few days, perhaps I can implement it.

I want to add support for WindowTinyLfu policy (#249) in addition to the current TinyLfu policy, so I am thinking of adding a method to the CacheBuilder to choose a cache policy. I will add another policy Lru, which has the LFU filter disabled. (I mean, for now, I will add the method to choose a cache policy; TinyLfu or Lru. I will work on WindowTinyLfu not this time, but in the near future.)

[ben-manes]

my hope in Caffeine was that users wouldn't need to make these type of algorithmic decisions. That was because their intuition may be wrong, the workload could change, it might disallow me from making improvements, and I did not want any deterministic expectations for the policy (e.g. users asserting strict LRU ordering in tests). Thankfully Caffeine users who had similar problems were patient, provided traces, and used their own forks or workarounds so my api didn't change.

The hill climbing with jitter has been very effective in all the traces that I have tried. The climber adapts to favor recency and jitter avoids an excessively hot victim from disallowing admission over long runs (e.g. a hash flooding attack). It's a tricky balance but I cannot recall any trace where Caffeine was not the leader, matched, or more than a -2% hit rate for non-weighted caches (gdsf is a champ and I spend less time evaluating weights as not common in Java due to GC). When reports are made that another policy has a substantial improvement, like the recent CMU papers, from what I can tell it been due to their own implementation differing substantially from Caffeine's. I am always on the look out because no algorithm is perfect and I have improvement ideas but not enough data to be worth trying them.

[tatsuya6502]

@PhotonQuantum

This seems an easy task for me. If you can wait for a few days, perhaps I can implement it.

OK. I implemented the LRU policy via #390 and published v0.12.5 to crates.io. The LRU policy has the LFU admission filter disabled.

# Cargo.toml

[dependencies]
moka = { version = "0.12.5", features = ["sync"] }

use std::time::Duration;
use moka::{policy::EvictionPolicy, sync::Cache};

let cache = Cache::builder()
    .eviction_policy(EvictionPolicy::lru())
    .max_capacity(...)  // optional
    .time_to_idle((Duration::from_secs(...))
    .support_invalidation_closures()
    .build();

• https://docs.rs/moka/0.12.5/moka/policy/struct.EvictionPolicy.html
• https://docs.rs/moka/0.12.5/moka/sync/struct.CacheBuilder.html#method.eviction_policy

[PhotonQuantum]

Amazing! Thank you for your quick response and implementation!