Say why a VS chunk chain is lost, and stop claiming it cannot be - #109
Conversation
|
Warning Review limit reached
Next review available in: 36 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
`unplaced_bytes` has sat at exactly 290,816 over 19 extents on four consecutive
live walks, which is too stable to be damage and was unexplained. It is now
explained, and the explanation contradicts a claim I put in `walk_vs`'s own
documentation: that the chain always crosses a hole, because a decommitted
range is the interior of a free chunk and the allocator keeps its headers
reachable.
True of decommitted memory. A hole is not only decommitted memory. On the live
target the chain named a header inside every hole it failed to cross, and
`!pte` on those addresses says why:
VA ffffdf080c20ce00 ... PTE contains 00007DDE00000084
not valid PageFile: 0 Offset: 7dde Protect: 4 - ReadWrite
A pagefile PTE, not a zero one: paged pool that is committed and paged out. The
header really is there and a KD link cannot fault it in, so those bytes are
unreachable from a live target rather than missing from the pool — and the same
walk against a dump carrying paged memory would not lose them.
The diagnostic splits into its two causes, since `PoolDiagnostics` folds numbers
but not words and a walk should say which it met: 13 extents whose chain named
an unreadable header, and 6 further extents in those same regions that were
already lost. It also carries how far back the named header is, which is what
placed it inside the hole rather than before it.
No behaviour change. This is the walk explaining a number it already reported.
f2c3776 to
bc60139
Compare
1 participant
Rebased onto
mainnow that #108 has merged. Diagnostic wording and documentation only,no behaviour change.
What
unplaced_bytesactually isIt has been exactly 290,816 bytes over 19 extents on four consecutive live walks —
the same extents at the same addresses each time. Too stable to be damage, and until now
unexplained.
Splitting the diagnostic by cause gives 13 extents whose chain named a header it could
not read, and 6 more in those same regions that were already lost behind them. Carrying
how far back the named header is put it inside the hole rather than before it:
which contradicts the reason I gave in
walk_vsfor believing the chain always crosses ahole: that a decommitted range is the interior of a free chunk, so the allocator has to
keep its own headers reachable.
That is true of decommitted memory. A hole is not only decommitted memory.
!pteoneach named address:
A pagefile PTE, not a zero one — paged pool that is committed and paged out. The
header is really there; a KD link simply cannot fault a page in. So
unplaced_bytesisnot a walker defect and not corruption: it is memory unreachable from a live target,
which is why the figure is identical run to run on an idle VM and why the same walk over
a dump carrying paged memory would not lose it.
Why nothing is being recovered here
The obvious next step would be to re-anchor from
reusable_chunks/cached_chunks— thefree-tree and delay-free chunk addresses the walk already collects are validated chunk
boundaries, so resuming from one inside an unplaced extent would not be a guess. I have
not done it, and I do not think it is worth it: 290,816 bytes is roughly 0.3% of a walk
that reaches 446k chunks, the recovery would be partial (only where a free chunk happens
to start in the extent), and it adds a second way for the chain to be wrong in exchange.
Worth revisiting only if this figure ever grows.
Verification
cargo test(125 pass),cargo clippy --all-targetsclean, re-run after the rebase. Thewording was read off four live runs; the last one produced the samples quoted above.