Repository navigation
perf(memory): reduce repeated write-tracking range scans - #1310
Conversation
5a715a4 to
f26ea47
Compare
|
The range is now selected before the walk. Linux widens it only after checking watched coverage. Windows keeps the requested range because its arena check does not prove that neighboring pages are committed. A failed walk returns without a retry. I also compared upstream Version checks, ns/check (upstream → PR):
The saved 4,172-request replay fell from 471.4 to 418.4 ns/request with clean pages, and from 496.3 to 435.6 ns/request with a write every 64 requests: 11.2% and 12.2% less time. The observed run ranges did not overlap for either replay case. The early-exit cases are about 1 ns slower. This replay preserves request ranges and epochs, not the complete game workload; it does not establish a frame-time gain. Write-history and graphics tests pass. Write-tracking tests also pass with caching disabled and with the shared cache enabled. Windows was not tested. |
|
Tested on Windows, since the description says it wasn't: Windows 10 (19045), RTX 3060 Laptop (driver 616.92), MinGW-w64 GCC 15.2.0, Release,
|
|
Conflicts with main in |
Scan version stamps within contiguous leaves. On Linux, collect nearby pages within queue epochs only after confirming full watched coverage. Keep the requested range on Windows. Select the range before collection and do not retry a failed walk. Test sparse-leaf boundaries, write histories, partial unwatches and epochs. Fedora 44 Release tests pass with default, disabled and shared caching. Isolated upstream comparison reduces the saved collect replay by 11-12%. Windows was not tested. AI-assisted: yes.
|
Rebased on current |
f26ea47 to
1a0c999
Compare
…nge-scans perf(memory): reduce repeated write-tracking range scans
Linux widens a collect of at most one 64 KiB block to the whole block within an epoch (boykopovar#1310), so the memo serves the block's other ranges. Windows kept the requested range because it was not tested there. On Windows with boykopovar#5596's resident direct memory every walk is a GetWriteWatch call, and ASTRO BOT's hub walks about 50k ranges of at most 64 KiB per 10 s on queue 0. Windows coverage does not know which pages of a block are committed or inaccessible, and a walk refuses such a range before it collects anything. So a widened walk that fails is retried over the requested pages; without that, a collect beside uncommitted pages of its block fails. agc_driver_image_table_reuse expected one more table resolution on Windows than on Linux, from the narrower collects; it now expects Linux's count on both. The new uncommitted-pages test resets its range before releasing it, so the arena does not hand the next test an address inside memory that is still committed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4 participants
What
Scan version stamps within each contiguous leaf instead of finding the leaf for every block. On Linux, collect nearby watched pages together within existing queue epochs.
Select the range before collection. Widen it only when Linux confirms full watched coverage. Keep the requested range on Windows, for uncached reads, and for threads without epochs. Do not retry a failed collection.
Related: #1201 and #1202 change queue scheduling and retain more collected ranges. This change keeps epoch boundaries and the existing cache size.
Tested
Fedora 44, Release build:
Isolated comparison against upstream
a9ba39c9: unchanged 64 MiB checks fell from 510 to 208 ns. A saved 4,172-request replay used 11–12% less time. Checks that found a write at the first block were about 1 ns slower. These are component timings, not title frame times. Windows was not tested.Checklist
main; related PRs are described above.