U-Boot Block Cache Statistics: Showing Counters Does Not Make the Next Read Cold

Two consecutive blkcache show commands can report
activity and then zero hits and misses while the same cached blocks
remain available. In U-Boot v2025.01, reading the statistics resets
those counters but does not discard cache entries.

That distinction matters when comparing first and repeated filesystem
reads. A fresh measurement interval and an empty cache are different
starting conditions. Neither should be inferred from a screen showing
zero counters.

Separate counters from
cached contents

The blkcache
command guide describes show as displaying and
resetting statistics. The command
implementation obtains one statistics snapshot and prints hits,
misses, current entries and the two configured capacity limits.

The cache
implementation makes the reset scope precise.
blkcache_stats() copies the statistics structure to the
caller and clears only hits and misses. It leaves entries and capacity
settings intact.

A second immediate display can therefore show zero activity with
nonzero entries. That is an expected interval-counter result. It does
not mean that the cache forgot the data, that the first display was
wrong, or that a later read must reach the device.

Reapplying
the same limits is not an invalidation

blkcache_configure() compares both supplied limits with
the current limits. It invalidates all entries only when at least one
limit changes. It then stores the limits and resets hits and misses
regardless of whether invalidation occurred.

Consequently, issuing a configure operation with the existing values
establishes another zero-counter interval while keeping the cache warm.
The command’s confirmation text does not say whether any setting
actually differed. Inspect the before-and-after entry count and exact
configuration rather than treating every successful configure call as a
flush.

If a controlled experiment needs invalidation, make that operation
explicit in the experiment design. A deliberate temporary capacity
change followed by restoration causes invalidation in this
implementation, but it also changes measurement state and must be
recorded. No cache configuration was changed for this article.

Understand what counts as a
hit

A matching entry must have the same interface type, device number and
block size, and must contain the entire requested block interval. The
request need not exactly equal the cached interval: a contained subrange
can be served by copying the corresponding bytes.

The lookup does not assemble one request from multiple adjacent
entries. A request spanning two cached ranges can therefore miss even
when those ranges collectively contain all requested blocks. Request
shape, not just byte coverage, affects the reported hit count.

On a hit, the entry is moved toward the most-recently-used position.
When filling a full cache, the implementation reuses the
least-recently-used entry. Reads larger than the configured per-entry
block limit are not inserted by the fill routine, and a zero entry limit
prevents insertion. A miss is thus not proof that the next identical
operation will become a hit.

Use
paired observations with a declared starting state

For a proposed fixture, record limits and entry count before the
workload. Capture one statistics snapshot to establish the interval
boundary, perform the intended read sequence, and capture the next
snapshot. Preserve both snapshots; a later observer can reset the
counters before the measurement collector sees them.

Qualify contained-subrange and spanning-range requests separately.
Keep device identity, block size and requested block counts available
alongside any higher-level file-operation trace. One filesystem
operation can perform several block requests, so its count need not
equal cache misses.

This is a block-cache accounting model, not a measured speedup or a
complete model of filesystem and hardware caching. No read benchmark was
run. A useful result states both the cache-content starting condition
and the counter interval; only then can the numbers explain what the
workload actually reused.