[matrixarkai]

Every read row in the allocation report was a memory hit. A read that misses
memory and finds the entry on the SSD tier does more than fetch it: before it
returns, it puts the entry back into memory, which is an admission — and an
admission into a full tier evicts. That work is on the reader, and nothing
measured it.

a 1 KiB value, incompressible	allocations	bytes
get, served from memory	1.00	1,024.0
get, promoting from a lower tier	13.00	25,334.0

Thirteen times the allocations and twenty-five times the bytes of the same
read served from memory.

The figure is identical on both feature arms, which says the cost is on our
side of the store rather than in the backend: the block was written through at
put time, so the eviction the promotion triggers finds the victim already on
the device and writes nothing.

The row asserts its own regime

Each read is checked to have found the value, and afterwards the cache is
asked how many of the reads reached a lower tier. Memory holds sixteen of the
five hundred and twelve keys and the reads walk the whole range, so all but a
handful have to come off the SSD tier.

Without that check, a larger memory capacity or a placement change would
leave the row reporting the cost of a memory hit under the promotion label —
a probe that quietly stops entering the regime it argues about agrees with
whoever reads it.

The fixture fills with incompressible bytes, as the other tiered rows do, or
the blocks shrink and the memory capacity is never exceeded.

Gates on both feature arms: cargo fmt --check, clippy --all-targets -D warnings, both suites, the vocabulary check, and both reports with
--require-passed.

🤖 Generated with Claude Code