arch-amdgpu: improve page-walk caching and TLB coalescing - #2
Open
Basemism wants to merge 12 commits into
Open
Conversation
This commit fixes the instruction execution latency of LDS instructions based on what microbenchmarks suggest
The LDS uses 4 byte wide banks in most GPUs. This requires each 4B address to map to a bank. The previous model mapped each byte to a bank and introduced several bank conflicts. This commit fixes the bank mapping to map each 4B word to an LDS bank Change-Id: Iaca0bcd3525a31c4ae55e379bf341a1de3ef8b31
Change-Id: I6dc1c9118027434a9e0bd26cc3843d3f56d955ad
Previously, the LDS model assumed each instruction has the same bus data transfer costs. This commit updates that to use the instruction dword length instead Change-Id: Id3decd6bb6fba3c50c84377ac5c7550660113092
Previously, `GlobalMemPipeline::getNextReadyResp` only checked the absolute oldest request in the entire ComputeUnit. If this single request was incomplete, it blocked all subsequent completed requests from being processed, degrading global memory pipeline performance. This commit updates the response selection logic to pick the oldest completed request on a per-wavefront basis. This prevents a single stalled wavefront from starving the entire CU, improving overall global memory pipeline throughput. Change-Id: Ia9bfde40a1940f450aee181ab816cc47dc677644
Introduce separate fabric_clk and memory_clk for the GPUFS, replacing the single ruby_clock domain. Change-Id: I817ab2e5a215b76728fd31dcc067535fd6590126
Previously, gpu clock was not applied to the model Change-Id: Ic3e39f984bc79fc0787282bb73d004a1f474e904
Extend the Vega page-table walker with a second page-walk cache for valid neighbouring final-level PTEs fetched in the same memory block. Keep the existing PWC for non-final walk levels and defer insertions until the walker knows whether an entry terminates the walk. Add pwc_fetch_bytes to control aligned page-table memory requests, propagate it to GPU, command-processor, and SDMA walkers, and validate that the width is a supported power-of-two multiple of a PTE. Track accesses, hits, misses, insertions, invalidations, and rejected invalid neighbours separately for the two caches.
Track Vega TLB lookup outcomes by page size and extend lookups to the large page sizes the walker can install. Probe additional page sizes during a walk and clamp page sizes used as coalescer keys so a giant mapping cannot serialize an unbounded address region. Add adaptive predictors for page size and coalescing distance, together with statistics for their decisions and outcomes. Preserve request completion and retry ordering while allowing coalescing granularity to follow observed TLB behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Apologies for the incoming word vomit.)
This PR improves AMD GPU page-table walking and TLB request coalescing in two related parts:
PWC changes
The page-table walker now maintains two caches:
The existing PWC continues to cache intermediate page-table entries, but does not cache final-level PTEs. Final translations are already cached by the TLB, so storing them in the original PWC would duplicate entries and consume capacity intended for intermediate walk levels.
The neighbour PWC caches valid final-level PTEs returned in the same aligned memory fetch as the requested PTE. For example, a 128-byte page-table fetch contains sixteen 8-byte PTEs. The walker consumes the requested PTE immediately and inserts the other valid leaf PTEs into the neighbour PWC for later translations.
This makes use of data already returned by the page-table memory request. Translations for nearby pages may subsequently complete from the neighbour PWC without another memory access.
The page-table fetch width is configurable through
pwc_fetch_bytes. Requests are aligned to that width, and the requested PTE is selected from the returned block. The configuration is validated to ensure that the width is a supported power-of-two multiple of the 8-byte PTE size.Insertion is deferred until the walker determines whether an entry is intermediate or final-level:
Page-table invalidations apply to both PWCs. The block-fetch and extraction behavior is implemented for both timing and functional page-table walks.
Separate statistics are provided for accesses, hits, misses, insertions, and invalidations in each PWC, along with the number of invalid neighbouring PTEs skipped.
TLB lookup changes
The TLB lookup path now checks every page size that the Vega page-table walker can install: 4 KiB, 2 MiB, 1 GiB (, and 512 though I haven't tested this path)
For each candidate page size, the virtual address is aligned to that page-size boundary before the TLB key is constructed. This allows any address within a large mapping to find the entry installed for the mapping’s base address.
Page-size prediction
Before translation completes, the coalescer must choose the address range over which requests may share a TLB lookup.
Previously, requests were initially grouped using a fixed assumed page size. If the completed translation returned a different size, the requests had to be removed and re-coalesced using the actual size. A workload that repeatedly used the other page size therefore repeated the same incorrect initial grouping for each lookup.
This PR adds a saturating predictor that chooses between 4 KiB and 2 MiB when constructing the initial coalescing group. The predictor is trained using the page size returned by completed translations.
If the prediction is incorrect, the affected requests are removed from the speculative group and re-coalesced using the actual page size. This preserves the previous fallback behavior while avoiding repeated re-coalescing when a workload exhibits stable page-size behavior.
Page sizes larger than the maximum supported coalescing granule are clamped to that granule. A 1 GiB or 512 GiB mapping therefore cannot serialize requests from the entire mapping behind a single coalescer entry.
Adaptive neighbour-PTE coalescing
Fetching adjacent leaf PTEs is most useful when nearby translation requests can share the resulting neighbour-PWC entry block.
The L3 TLB coalescer can widen a request group to cover the virtual pages represented by one pwc_fetch_bytes block. A second saturating predictor decides whether to apply this wider coalescing based on previous translation outcomes:
This is important because both a PWC hit and a page-table memory access pass through the walker, but only the memory access retrieves new neighbouring PTEs.
When speculation is incorrect, the implementation preserves request completion, retry handling, and coalescer FIFO accounting while requests are regrouped.