From: paaronclayton@gmail.com   
      
   On 2/8/26 5:57 PM, BGB wrote:   
   > On 2/5/2026 11:23 PM, Kent Dickey wrote:   
   >> In article <1770238707-5857@newsgrouper.org>,   
   [snip]   
   >> I think the 32-entry fully associative is the primary TLB.   
   >> The 1024 entry   
   >> is a secondary TLB.  Hits in the primary TLB cause no stalls   
   >> at all.   
   >> Misses in the primary probably lead to stalls (but it is   
   >> possible the   
   >> 6 cycle latency can be hidden sometimes), so it costs   
   >> performance.   
   >>   
   >> If the primary TLB (the one with no stalls) is only 4 entries,   
   >> then   
   >> we can easily calculate a pretty substantial stall penalty for   
   >> most   
   >> programs since it will pay the 6 cycle stall a lot (and that's   
   >> for a L2   
   >> TLB hit).  So we make the L1 TLB as big as possible, but it   
   >> cannot be made   
   >> too large or its too slow, so it ends up between 32- and   
   >> 128-entries   
   >> (256 tops).   
   >>   
   >   
   > Full associativity isn't worth it.   
   >   
   > The gains from more associativity seem to max out at around   
   > 8-way, and 32 pages isn't nearly enough coverage (very high TLB   
   > miss rates would be unavoidable).   
      
   Full associativity is not just about conflict misses. Such also   
   facilitates supporting multiple page sizes in the same TLB.   
   Different page sizes naturally use different indexing bits, so   
   having zero indexing bits means that any page can occupy any entry.   
      
   André Seznec proposed a way to use (overlaid) skewed   
   associativity to support multiple page sizes ("Concurrent   
   Support of Multiple Page Sizes On a Skewed Associative TLB",   
   2003). This has the limitation of requiring shared indexing bits   
   so that the different page size probes (done in parallel) can be   
   mapped to different banks. This also requires accessing more   
   entries with limited associativity (the skewed associative   
   conflict avoids reduces the miss rate that this would otherwise   
   cause as well as balances utilization among page sizes).   
      
   AMD used full associativity to support coalescing of 4KiB pages   
   into 16KiB (32KiB in Zen+ and earlier) TLB entries. (An ordinary   
   8-way associative TLB indexed for 16KiB "pages" would map all   
   uncoalescable 4KiB pages in a 16KiB chunk to the same set,   
   increasing conflict misses.) It might have been possible to   
   index by the shared bits of coalesced and base page sizes and   
   use a CAM-based predictor to choose whether to index the rest by   
   base page or by coalesced page, but I suspect such would not be   
   that much smaller than using full associativity and likely   
   slower more power consuming as well as vulnerable to false   
   conflicts from the predictor limiting which PTEs can share a set.   
      
   Full associativity may also have been important for Itanium 2's   
   prevalidated cache, where each cache tag had one hot bit   
   indicating which TLB entry applied to it. This allowed faster   
   tag check and flash invalidation of (write-through) cache   
   entries when a TLB entry was evicted. The number of bits in the   
   cache tag limits the TLB capacity, which makes associativity   
   more important, and TLB misses are more expensive since they   
   might invalidate useful cache blocks. (Write through may have   
   been desirable for reliability or been a consequence of seeking   
   a low latency mechanism for L1 accesses.)   
      
   Of course, the tradeoffs are different for an FPGA implementation.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)