Leak claims Nova Lake CPUs with reduced E-cores may retain full L3 cache pool

The leak revises earlier predictions that Intel would proportionally reduce L3 cache alongside disabled E-cores in Nova Lake. Instead, some SKUs with partially disabled E-core clusters may retain the full cache pool of their fully-enabled counterparts. This creates a non-linear relationship between core count and cache size, where 8P+12E and 4P+4E configurations now match the 36MB and 18MB cache of 8P+16E and 4P+8E SKUs respectively. The inconsistency extends to the 6P+12E variant, which remains at 27MB rather than adopting the 30MB cache of its 6P+16E counterpart.

For engineers, this design choice complicates performance modeling. Cache-sensitive workloads may see less degradation from E-core reductions than previously expected, particularly in mid-range SKUs. However, the lack of uniform scaling means each configuration must be evaluated individually. The mobile Nova Lake-HX lineup reportedly follows the same pattern, suggesting this is a deliberate architectural decision rather than a temporary binning strategy. Power efficiency calculations will need to account for the additional cache leakage current in these reduced-core SKUs.

The cache retention appears selective rather than systematic. While 8P+12E and 4P+4E SKUs gain cache, the 6P+12E configuration does not, indicating Intel may be prioritizing certain market segments. This could reflect different performance targets for desktop versus mobile, or simply internal segmentation that isn't yet visible in leaks. The separate bLLC cache for high-end SKUs remains unaffected by these changes, maintaining its 132MB and 108MB allocations for 8P+12E and 6P+12E variants respectively.

Adopting these SKUs may require revisiting platform assumptions. Systems designed around the earlier 33MB and 15MB cache predictions may now have additional thermal headroom or bandwidth capacity. However, the lack of official confirmation means these specifications could still change before launch. Engineers should treat these numbers as preliminary and avoid committing to cache-dependent optimizations until Intel provides official documentation.