Papers
Topics
Authors
Recent
Search
2000 character limit reached

Residual GPU Cache State on Apple M4 Pro

Published 25 Jun 2026 in cs.AR | (2606.27098v1)

Abstract: Apple silicon exposes unified CPU-GPU memory, but the cache state left after a completed GPU command is not documented. This paper characterizes that phase boundary on a 14-core Apple M4 Pro. We validate the measurement pipeline against unmodified STREAM 5.10 and BabelStream 5.0, then adapt an 8192-byte system-level-cache occupancy pattern to a synchronized Metal experiment. A GPU kernel touches 0 to 512 MiB and finishes before a 16 MiB CPU probe begins. The first CPU traversal is slower after large GPU footprints, while a second traversal removes most of the cost, showing residual shared-cache displacement rather than simultaneous DRAM contention. A separate matched-block experiment measures GPU slowdown under high-priority CPU traffic and finds background QoS close to baseline. Root PMU measurements and public IOReport histograms provide hardware grounding: they distinguish L1D refill sectors from software cache-line size, expose page-offset-dependent conflict behavior, and separate performance-core, efficiency-core, and AGX demand. The results identify a reproducible post-GPU cache-displacement window on M4 Pro and quantify a simple one-pass software recovery mechanism.

Authors (2)

Summary

  • The paper demonstrates that GPU command completion on Apple M4 Pro leaves significant residual cache state, causing up to a 63% penalty on CPU traversal speeds.
  • It employs robust pointer-chasing and SLC-selective probing to differentiate cache state effects from DRAM contention with precise PMU measurements.
  • Experimental results indicate that explicit rewarming and QoS adjustments, rather than resource descriptor changes, are effective in mitigating cache penalties.

Residual GPU Cache State on Apple M4 Pro: A Detailed Analysis

Introduction

The presented study rigorously characterizes cache state persistence in Apple’s M4 Pro SoC, focusing on the effect of completed GPU (Metal) commands on the subsequent CPU-observable cache state. The investigation targets the Apple M4 Pro's heterogeneous architecture, which features a unified memory subsystem and system-level cache (SLC) shared between CPU and GPU clusters. The work addresses an empirically unresolved, yet practically crucial, question: After GPU work concludes with synchronization, what remains in the shared cache, and how does it affect subsequent CPU access patterns and performance? Prior studies reverse-engineered analogous behavior on Apple M1, but direct measurements and validations for M4 Pro have not previously been reported.

Experimental Methodology

A multifaceted, methodologically robust measurement pipeline is deployed. Upstream bandwidth calibration leverages unmodified STREAM 5.10 and BabelStream 5.0 for baseline performance validation, yielding results within 3% margin—establishing the accuracy of the custom triad benchmarks.

Critical latency characterization is grounded in pointer-chasing traversals constructed to eliminate prefetch effects and to differentiate between SLC residency and DRAM access. The post-GPU cache-displacement effect is isolated using an SLC-selective access pattern, adapted from Xu et al., which distributes one cache-line touch every 8192 bytes to minimize L2 set conflicts and ensure SLC occupancy. Metal kernels induce GPU footprints between 0 and 512 MiB, after which a CPU probe evaluates cache residency through precise timing. Two traversal passes are performed to distinguish between direct bandwidth contention and recoverable cache-state effects.

Hardware-level validation uses the root-enabled PMU interface to record L1D, L2, and DRAM events, refining prior assumptions about line size, refill granularity, and associativity. Concurrent QoS contention is examined by manipulating macOS Quality of Service (QoS) classes to study how both prioritized and background CPU workloads influence GPU throughput and vice versa.

Key Findings

Reproducible Cache Residency Penalty

The study establishes a reproducible, significant penalty after GPU completion: for a 16 MiB SLC-selective CPU probe, the initial traversal is 31% slower following a 64 MiB GPU footprint and 63% slower following a 512 MiB footprint. This is robust over 51-trial medians and bootstrap confidence intervals. Notably, a second traversal recovers 24% (64 MiB experiment) and 38% (512 MiB experiment) of the penalty, nearly restoring performance to the no-victim baseline, thereby validating the effect as residual shared-cache state, not DRAM contention.

Resource Modes and Texture Hints

Systematically randomized combinations of Metal buffer and texture storage modes, including access optimization hints provided by the Metal blit encoder, do not mitigate the observed post-GPU cache-displacement penalty. Variation among resource paths for the highest GPU footprint is statistically insignificant (<3.3 percentage points across paths), indicating that, on M4 Pro, such descriptors only alter resource representation and not cache cleansing.

PMU Insights

L1D refill sector on performance-cores is empirically determined as 64 bytes, though macOS reports a 128-byte coherence granule—disambiguating line size for low-level tuning. The measured random-access latency curve and L1D miss rate precisely delimit the 128 KiB L1D and 16 MiB L2 regions; the SLC residency transition occurs at working-set sizes above L2. Importantly, 16 KiB page-stride associativity sweeps reveal that the physical set-mapping function is more complex than a page-bit-derived mapping, precluding simple construction of minimal eviction sets on this hardware.

macOS Scheduling and QoS

macOS does not expose core-level pinning, even with root privileges. Scheduling is only steerable at the cluster (performance vs. efficiency) level via QoS. Cycle-accurate PMU measurement confirms that user-interactive QoS enables full core frequency, while background QoS throttles the job and migrates it to the efficiency cluster, with a corresponding drastic reduction in attainable bandwidth (e.g., CPU stress drops from 189.8 GB/s to 15.6 GB/s).

Bandwidth Contention and Interference Policy

Live IOReport agent histograms and timing reveal that high-priority CPU and GPU workloads saturate their respective memory controller agents with substantial interference (16% median GPU slowdown under prioritized concurrent CPU load). Background-class CPU work, managed by QoS, preserves GPU throughput, confirming that QoS on macOS acts as a real-time interference policy within the unified memory hierarchy.

Implications and Recommendations

Practical Implications

  • Completion is not quiescence: The completion and synchronization of GPU commands guarantee execution and data visibility but do not restore previous CPU working-set residency in the SLC. Developers must not assume cache residency is unaffected by prior GPU operations.
  • Explicit rewarming removes penalties: An intentional, single-pass traversal (rewarm or prefetch) can resynchronize CPU cache state, mitigating the penalty after a broad GPU access. For workloads with known reuse patterns, scheduling such traversals outside critical paths, or overlapping them with unrelated computation, is effective.
  • Resource descriptors do not help: Choices related to Metal buffer/texture modes or optimization hints are not cache-flush primitives on M4 Pro and thus cannot be relied upon for architectural cache state management.
  • QoS policy as an interference lever: Explicitly marking non-time-critical CPU memory traffic as background class preserves GPU throughput but at a steep cost in CPU throughput, making such policies suitable only for specific, throughput-insensitive workloads.

Theoretical Implications and Future Directions

This work delineates systemic boundaries for microarchitectural reverse engineering on Apple silicon beyond M1, highlighting that architectural details such as set-indexing and minimal eviction set construction require privileged (kernel) access not available on commodity OS configurations. The durability of post-GPU residual cache state indicates design decisions that prioritize throughput and power efficiency over full cache flushing across execution domain transitions.

Future research directions include:

  • Exploring kernel-level or RecoveryOS-enabled experimentation for physical address control and timing.
  • Detailed modeling of replacement policies and congruence behaviors.
  • Quantitative evaluation on additional Apple silicon generations and form factors.
  • Extension to production GPU kernels and mixed CPU-GPU AI workloads.

Conclusion

The Apple M4 Pro system does not guarantee automatic CPU cache residency restoration after Metal GPU command completion. Residual shared-cache state can cause CPU access penalties up to 63% after broad GPU accesses, but a single planned CPU traversal recovers most of this effect. Resource descriptors or storage modes do not clear residual SLC state. Effective cache management strategies on M4 Pro require explicit software-level prefetching, and QoS tuning acts as a reliable lever for inter-cluster bandwidth arbitration. This work refines the operational understanding of unified cache architectures in Apple silicon, with direct implications for the performance engineering of heterogeneous workloads.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 1 tweet with 15 likes about this paper.