Re: PATCH v4 0/6] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation

[Kenneth Crudup]

On 4/30/26 12:18, Matthew Brost wrote:

> Introduce zone_maybe_fragmented_in_shrinker() as a lightweight helper to
> allow subsystems to make coarse decisions about reclaim behavior in the
> presence of likely fragmentation

I'm running Linus' master on my LunarLake (258v) laptop, and sometimes 
after compiling a kernel (of all things) I'd see kswapd0 thrash despite 
having quite a bit of free memory.

I finally traced it to the xe driver after seeing the "GPUActive" field 
in /proc/meminfo suddenly start rising, eventually growing larger than 
real memory by several times (see below).

This patchset fixes the issue, and I'm sure there'll be a fix going into 
Linus' master soon, but what I'M wondering is how could building a 
kernel (which is just in a KDE Konsole running on Wayland) make the 
GPActive grow from ~1.6G to > 30G (and continue to rise, RN I'm seeing 
91839848 kBs and still growing).

-Kenny

----
SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUActive:        652640 kB
GPUReclaim:       403988 kB

SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUActive:        651180 kB
GPUReclaim:       406812 kB

SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUActive:        659004 kB
GPUReclaim:       399396 kB

SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUActive:        666996 kB
GPUReclaim:       392764 kB

<some hours later>
GPUActive:      91832468 kB
SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUReclaim:       488000 kB

GPUActive:      91832332 kB
SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUReclaim:       487988 kB

GPUActive:      91869376 kB
SwapTotal:      33554428 kB
MemTotal:       32345672 kB
GPUReclaim:       486504 kB
----

--
Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange 
County CA