The change helps a protected allocation compete for device memory before falling back elsewhere. It does not create extra VRAM or make every protection setting equally strong.
From the patch series to the code
Natalie Vock’s August 4 series, applied August 5, addresses protected allocations falling back to GTT while unprotected buffers occupy VRAM. It also fixes how protection is evaluated between sibling cgroups and broader subtrees.
The Linux 7.3-rc2 TTM code distinguishes two cases: low protection is best effort, while min is stronger. An allocation below min can consider evicting low-only buffers; one below low follows a path that targets buffers protected by neither. Saying “protected buffers never compete” would hide that distinction.
A protection is not an empty reserved block
The cover uses an invented allocatable pool of 8 GiB. Workload A occupies 3 GiB under a 4 GiB protection; workload B occupies the other 5 GiB without protection. A new 1 GiB request from A can require displacing 1 GiB of B to use A’s remaining allowance.
Nothing in that illustration adds memory. It changes who occupies an existing pool, and assumes an eligible buffer can be evicted. The diagrams do not claim a real card always has 8 GiB available to these workloads or that every allocation succeeds.
Read capacity and hierarchy together
The DMEM documentation defines byte-based region accounting and distinguishes configured limits, current use and capacity. It notes that the kernel reserves some memory for internal use. Driver exposure and the configured cgroup policy therefore matter; a physical GPU capacity printed on a box is not the whole allocation budget.
For a contention test, record which device region is managed, its effective protection hierarchy and the competing workloads. Observe where buffers are placed and whether latency improves, rather than treating a successful limit write as a performance result.
The practical improvement is the opportunity to reclaim eligible space before falling back. It is a resource-policy correction. A blanket claim that every AMDGPU, Xe or Nouveau setup automatically becomes faster would go beyond that evidence.
September 8: inspect landed allocation code and DMEM documentation; distinguish min/low protection, hierarchy, configured allowance and physical capacity; remove all-driver and performance guarantees.