On Fri, Jul 31, 2026 at 11:00:49PM -0700, Matthew Brost wrote: > This actually roughly what downstream customers are carrying :). > > It is basically these 3 patches [9] [10] [11] implemented directly in > the Xe shrinker code to avoid touching the MM or TTM... > > Alas I got nack'd by someone outside my subsystem on this approach. > > I think if you use the reference patches above to implement a heuristic > in Xe, or come up with a similar one, it will likely solve this issue. > > Since you're on 6.18, you may also be missing some Xe/TTM changes > related to this problem that have already been merged into drm-tip. > There are a couple of one-line fixes that should help somewhat, but the > heuristic is what I think will actually address the root cause. > > As heads up, I've started looking at this again and pushing to get > something upstream as this at least 5th time someone or org has flagged > this as a problem. Any data you can provide will help us push towards a > solution.
Hi Matt, Thanks. I tested [9]-[13] on the same machine and the fragmentation heuristic does reduce the frequency of the problem. However, after these tests I would like to clarify my actual requirement, since my previous watermark-based proposal did not express it correctly. For BOs that belong to a latency-critical visual processing working set, I think userspace should be able to mark them as non-shrinkable, and Xe should not back them up under any memory-reclaim condition while that mark is held. This would be a hard residency contract, not another reclaim priority or a fragmentation hint. Why a hard contract is useful for visual workloads -------------------------------------------------- The reproducer is continuous 4K60 HDR playback. Every decoded frame is imported through DMA-BUF and processed by libplacebo/OpenGL for HDR tone mapping before presentation. The active BO set contains decoded video surfaces, intermediate render targets and presentation-related surfaces. At 60 Hz the complete frame interval is 16.667 ms. If glFlush() is blocked for longer than this, the application misses at least one presentation deadline. Repeated missed deadlines are perceived directly as dropped frames or visible stutter. A 100-500 ms reclaim/restore storm is an obvious freeze, even if the system eventually recovers and its average throughput looks normal. Fence-idle is not equivalent to cold for this workload. A video surface can have no active fence in the small gap between two frames and still be part of the application's current visual working set. The next frame can need the same BO immediately. The trace demonstrates exactly this case. In one sequence, kswapd completed backup of an 8,208-page BO and the rendering thread started restoring the exact same ttm_tt about 33 microseconds later. The kernel copied about 32 MiB to shmem, dropped the WC pages, then immediately had to allocate pages, copy the data back and reapply WC. In the ten-minute default-watermark capture: successful ttm_tt_backup: 4,853 ttm_tt_restore: 4,810 minimum backup+restore copy traffic: 50,436.105 MiB Flush > 16.667 ms: 209 Flush > 100 ms: 65 maximum trace-aligned Flush: 223.195 ms Of 4,791 restores matched to the same preceding backup, 4,279 happened within 100 ms and 4,753 within one second. kswapd0 performed 4,839 of the 4,853 backups, while the player's rendering thread performed most of the restores. Of the 209 Flush calls over one frame interval, 205 contained ttm_tt_restore() and all 209 contained set_pages_array_wc(). This is not useful recovery of cold memory. It is destruction and immediate reconstruction of the visible working set. What the heuristic test showed ------------------------------ I backported [9]-[13], extended the fragmentation check to direct reclaim, and tested a `high + min` watermark threshold. In a follow-up run with the same kernel, video and playback configuration, I set vm.min_free_kbytes to 50000. This lowered the Normal-zone `high + min` threshold from about 379.8 MiB to 255.1 MiB. With the lower threshold, the fragmentation helper returned true more often and Xe working-set churn fell by about 90%: successful ttm_tt_backup: 4,853 -> 443 ttm_tt_restore: 4,810 -> 435 Flush > 16.667 ms: 209 -> 19 Flush > 100 ms: 65 -> 3 This confirms that preventing working-set backup prevents the visual stalls. It does not make the individual restore path cheaper. When the heuristic still allowed a storm, the maximum Flush was 191.655 ms and contained 25 restores and 23 WC conversions. I do not think tuning global watermarks is the right solution. More importantly, I no longer think that protection for explicitly identified visual BOs should depend on whether reclaim was caused by fragmentation or genuine low memory. Once userspace has declared a bounded set as presentation-critical, violating that residency guarantee produces an immediate and user-visible failure. Possible explicit marking mechanism ----------------------------------- Could Xe provide an opt-in, mlock-like mechanism for this purpose? One possible interface would be a new DRM_IOCTL_XE_MADVISE VMA attribute, for example DRM_XE_VMA_ATTR_RECLAIM_POLICY, with states similar to: DRM_XE_VMA_RECLAIM_DEFAULT DRM_XE_VMA_RECLAIM_NO_SHRINK NO_SHRINK would mean that the backing BO is excluded from the Xe shrinker while at least one protected VMA holds the attribute. Userspace would set it when a video/render surface enters the active visual pipeline and clear it after the surface leaves that working set. Unbind, VM destruction or file close would also release the holder automatically. For a BO shared by multiple VMAs, Xe could maintain a BO-level no_shrink_count, similar to the holder accounting already used for purgeable state. The shrinker would skip a BO with a non-zero count. I would prefer a separate shrinker-specific count rather than exposing TTM pin_count, because pinning also affects placement and migration, which is broader than the requested guarantee. The existing WILLNEED state does not provide this contract: it prevents purging of the contents, but the non-purge shrinker may still back up and unpopulate the BO. It also cannot simply be redefined because WILLNEED is the default state for all VMAs. SCANOUT is not sufficient either, since many HDR intermediate and imported video surfaces are not scanout BOs. I understand that an unprivileged client must not be allowed to make an unbounded amount of memory unreclaimable. Like mlock, this could be controlled by an explicit per-file, per-client or cgroup byte limit, and possibly by a privilege check. If the requested protected set exceeds the configured limit, the madvise should fail rather than silently accepting the mark and later violating it under pressure. The application or system service would then decide which visual surfaces to protect or release. Within that bounded contract, however, I think NO_SHRINK should remain a hard guarantee even in genuine low-memory reclaim. Under pressure the kernel may reclaim unmarked BOs and other memory, reject additional NO_SHRINK requests, or require the application/service to release part of its protected set. Backing up an already accepted presentation-critical BO and stalling a frame by hundreds of milliseconds defeats the purpose of the interface. For comparison, my original workaround approximated such a hard contract by excluding VM-bound WC BOs from non-purge shrinking. In a 21-minute capture, no XE_EXEC, VM_BIND or DMA-BUF ioctl exceeded the 16.7 ms frame interval; their maxima were 348 us, 136 us and 20 us. The call rate of set_pages_array_wc fell to 0.179/s. That automatic VM-bound WC rule is too broad, but an explicit and bounded userspace mark could provide the same latency guarantee only for the BOs that actually need it. Would an explicit, bounded NO_SHRINK/latency-critical VMA attribute be a reasonable Xe UAPI direction? If so, I can prototype the BO holder accounting and shrinker exclusion, then modify the video/Mesa path to mark only the active visual working set and collect another strict A/B trace. [9] https://patchwork.freedesktop.org/patch/720030/?series=165329&rev=1 [10] https://patchwork.freedesktop.org/patch/720036/?series=165329&rev=1 [11] https://patchwork.freedesktop.org/patch/720031/?series=165329&rev=1 [12] https://patchwork.freedesktop.org/patch/732698/?series=168466&rev=1 [13] https://patchwork.freedesktop.org/patch/732420/?series=168389&rev=1 Thanks, Neil
