phongn opened a new pull request, #13234:
URL: https://github.com/apache/trafficserver/pull/13234

   ## Summary
   
   The tiered *seen filter* for the (default) LRU RAM cache never engaged at 
the documented fill levels: an integer-division bug made it engage only when 
the cache was 100% full, so a scan could pollute a partly-full cache.
   
   ## Root cause
   
   `proxy.config.cache.ram_cache.use_seen_filter` greater than 1 is documented 
to enable the seen filter once the cache is more than *n%* full (`2` = 50%, `3` 
= 67%, `4` = 75%, up to `9` = 90%). The check was:
   
   ```cpp
   (bytes >= max_bytes * (1 - (1 / cache_config_ram_cache_use_seen_filter)))
   ```
   
   `cache_config_ram_cache_use_seen_filter` is an `int`, so `1 / N` is integer 
division and is `0` for every `N > 1`. The expression collapses to `bytes >= 
max_bytes`, i.e. the filter engages only at 100% full, and values 2–9 all 
behave identically.
   
   ## Fix
   
   Rewrite the comparison so it is exact in integer arithmetic and 
overflow-safe at realistic cache sizes:
   
   ```cpp
   (bytes * cache_config_ram_cache_use_seen_filter >= max_bytes * 
(cache_config_ram_cache_use_seen_filter - 1))
   ```
   
   `N=2` → ≥50%, `N=3` → ≥67%, `N=9` → ≥89%, as documented. (Only the LRU RAM 
cache uses the tiered percentage; CLFUS treats the knob as on/off and is 
unaffected.)
   
   ## Test
   
   Adds `ram_cache_lru_seen_filter`: with `use_seen_filter = 2`, fill the cache 
to ~60% then `Put` 20 unseen keys once each — above the 50% threshold the 
filter must reject them. Verified it fails on the old form (20/20 admitted at 
60% full) and passes on the fix (0/20). The existing `ram_cache` regression 
test still passes.
   
   ## Impact
   
   Operators who set `use_seen_filter` to 2–9 to get scan resistance once the 
cache is partly full currently get none until it is completely full. This 
affects the **default** RAM cache (LRU).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to