phys_footprint
A process-level memory metric exposed by macOS through libproc. It is the value shown in the Memory column of Activity Monitor and reflects an estimate of physical pages actually resident and counted toward system memory pressure.
Timeline (last 90 days)
On an Apple Silicon Mac, after moving a PyTorch tensor on the MPS device to the CPU via .to("cpu"), the process's phys_footprint immediately drops to near zero, but the tensor data remains fully in memory.
phys_footprint is a process-level memory metric that macOS exposes through libproc, and it is what the Memory column in Activity Monitor displays; it is an estimate of 'physical pages that are actually resident and counted toward system memory pressure', excluding the portion swapped out to swap, so under a unified memory architecture it falls rapidly when pages are marked as compressible or enter swap.
MPS's driver_allocated_memory count and the process's phys_footprint are two independent ledgers, and both dropping in sync does not mean the memory has been released.
In the reproduction experiment (torch 2.14.0, macOS 26.5.2, M5 Pro 48 GB, 4 GiB tensor), right after moving to CPU both phys_footprint and the MPS driver count returned to near zero, and only after the CPU read through the copy page by page did the footprint return to 4.2 GiB, with the results of three runs completely identical.
When checking for yourself whether a model run on a Mac truly fits, you should look at swap rather than only at footprint: as long as swap grows during the task run, it does not fit no matter how good the footprint looks; at the same time you should refer to the system-level free memory percentage (kern.memorystatus_level).
All Facts (5)
On an Apple Silicon Mac, after moving a PyTorch tensor on the MPS device to the CPU via .to("cpu"), the process's phys_footprint immediately drops to near zero, but the tensor data remains fully in memory.
50%Unverifiedphys_footprint is a process-level memory metric that macOS exposes through libproc, and it is what the Memory column in Activity Monitor displays; it is an estimate of 'physical pages that are actually resident and counted toward system memory pressure', excluding the portion swapped out to swap, so under a unified memory architecture it falls rapidly when pages are marked as compressible or enter swap.
50%UnverifiedMPS's driver_allocated_memory count and the process's phys_footprint are two independent ledgers, and both dropping in sync does not mean the memory has been released.
50%UnverifiedWhen checking for yourself whether a model run on a Mac truly fits, you should look at swap rather than only at footprint: as long as swap grows during the task run, it does not fit no matter how good the footprint looks; at the same time you should refer to the system-level free memory percentage (kern.memorystatus_level).
50%UnverifiedIn the reproduction experiment (torch 2.14.0, macOS 26.5.2, M5 Pro 48 GB, 4 GiB tensor), right after moving to CPU both phys_footprint and the MPS driver count returned to near zero, and only after the CPU read through the copy page by page did the footprint return to 4.2 GiB, with the results of three runs completely identical.
50%