Open Intel's optimization manual from 2006 (Core 2) and 2024 (Meteor Lake). Both list the same L1D size: 32KB, 8-way. This isn't laziness — it's a hard geometric constraint baked into how modern CPUs hide TLB latency.

Every L1 cache access starts with a race: the cache indexes into its set array using the address, while the TLB translates the virtual address to physical in parallel. If the cache had to wait for translation, L1 latency would jump from 4 cycles to 20+. The trick is Virtually Indexed, Physically Tagged (VIPT): use virtual address bits to pick the set, then compare against physical tags once the TLB responds.

But this only works if the index bits are identical in the virtual and physical address. That's only guaranteed for bits below the page offset — for a 4KB page, that's bits 0–11. Cross that boundary and you get the synonym problem: two virtual addresses mapping to the same physical page could land in different cache sets, breaking coherence.

This gives us the fundamental VIPT constraint:

• num_sets × line_size ≤ page_size
• Therefore: max_L1_size = page_size × associativity

Plug in the numbers for x86:

• Page size: 4KB
• Line size: 64 bytes → 64 sets fit within a page (4096 / 64)
• 8-way associativity → 64 sets × 8 ways × 64 bytes = 32KB

Want a bigger L1? You have three unpleasant options:

• Increase associativity. 16-way would give 64KB — but doubles tag comparators, energy per access, and can hurt latency. AMD tried this in some designs; the tradeoff usually loses.
• Increase page size. Breaks binary compatibility with 4KB-page OSes.
• Page coloring. The OS assigns physical pages so synonyms can't collide. Linux tried this; it's fragile and constrains the page allocator.

Real example: Apple's M1 has a 128KB L1D — four times Intel's. How? ARM lets Apple use a 16KB page size. That quadruples the VIPT budget: 16KB × 8-way = 128KB. Apple didn't invent better cache technology; they got to change the page size because iOS controls the whole stack.

Rule of thumb: If you see an L1D larger than page_size × 8, the CPU either uses larger pages, higher associativity, or is paying with software-managed page coloring. There's no free lunch.