arch-amdgpu: improve page-walk caching and TLB coalescing

[Basemism]

(Apologies for the incoming word vomit.)

This PR improves AMD GPU page-table walking and TLB request coalescing in two related parts:

1. Adds a neighbour page-walk cache for final-level PTEs returned in the same aligned fetch block as the requested PTE.
2. Adds page-size prediction and adaptive PTE-block coalescing.

PWC changes

The page-table walker now maintains two caches:

1. 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.

2. 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:

• Intermediate entries are inserted into the original PWC.
• Valid neighbouring final-level entries are inserted into the neighbour PWC.
• Invalid neighbouring PTEs are not inserted.

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:

• A TLB miss that performs a page-table memory fetch trains toward block-wide coalescing because the fetch supplies neighbouring leaf PTEs.
• A direct TLB hit trains away from wider coalescing because no page walk or neighbour-PWC population was required.
• A walk resolved by either PWC is distinguished from a walk that accesses page-table memory. A PWC hit therefore does not train the predictor as though it fetched and populated another block of neighbouring PTEs.

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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.