Summary

The "application threads eviction requested with cache fill ratio" bucketed statistics (introduced in WT-14649) are computed with integer division, so every hard-eviction request below 100% cache fill lands in the < 25% bucket. The other three buckets (25-50%, 50-75%, >= 75%) effectively never increment, making the breakdown useless in the common case.

Root cause

In __evict_update_work (src/evict/evict_thread.c) the ratio is computed as:

uint64_t cache_fill_ratio = bytes_inuse / bytes_max;

Both bytes_inuse and bytes_max are uint64_t, so the division truncates to 0 for any fill below 100%. The subsequent cache_fill_ratio < 0.25 comparison is then always true.

Fix

Compute the ratio in floating point, keeping the existing 0.25/0.50/0.75 bucket comparisons:

double cache_fill_ratio = (double)bytes_inuse / (double)bytes_max;

Notes

• Pre-WT-17392 the same logic existed in a second copy in the now-removed src/evict/evict_lru.c; after the split there is a single live copy in evict_thread.c.
• Regression coverage added in test/suite/test_stat12.py: a config placing all eviction triggers above 50% of the cache, so a correct build records only the upper buckets while integer division would force everything into lt_25.