Re: [PATCH 3/3] drm/xe: Avoid shrinker reclaim from kswapd under fragmentation

[Matthew Brost <matthew.brost@intel.com>]

On Wed, Apr 22, 2026 at 10:22:56AM +0200, Thomas Hellström wrote:
> Hi,
> 
> On Mon, 2026-04-20 at 18:26 -0700, Matthew Brost wrote:
> > When the Xe shrinker is invoked from kswapd, a large amount of free
> > memory in ZONE_NORMAL relative to the high watermark is a strong
> > signal
> > that reclaim is being driven by fragmentation rather than true memory
> > pressure.
> > 
> > In this case, shrinking Xe memory is unlikely to help kswapd make
> > forward progress. Instead it can evict active GPU memory despite the
> > system still having substantial free memory, increasing residency
> > churn
> > and reducing GPU forward progress.
> > 
> > Detect this case and bail out early from the Xe shrinker when running
> > in
> > kswapd and ZONE_NORMAL has more than 2x its high watermark free.
> > 
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Cc: Carlos Santa <carlos.santa@intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_shrinker.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_shrinker.c
> > b/drivers/gpu/drm/xe/xe_shrinker.c
> > index 83374cd57660..e56afde83de6 100644
> > --- a/drivers/gpu/drm/xe/xe_shrinker.c
> > +++ b/drivers/gpu/drm/xe/xe_shrinker.c
> > @@ -236,6 +236,19 @@ static unsigned long xe_shrinker_scan(struct
> > shrinker *shrink, struct shrink_con
> >  	if (nr_scanned >= nr_to_scan || !can_backup)
> >  		goto out;
> >  
> > +	if (current_is_kswapd()) {
> > +		struct zone *zone = &NODE_DATA(sc->nid)-
> > >node_zones[ZONE_NORMAL];
> > +		unsigned long free_pages = zone_page_state(zone,
> > NR_FREE_PAGES);
> > +		unsigned long high_wmark = high_wmark_pages(zone);
> > +
> > +		/*
> > +		 * If we have 2x the high watermark free, this is
> > definitely
> > +		 * fragmentation
> > +		 */
> > +		if (free_pages > (high_wmark * 2))
> > +			goto out;
> > +	}
> > +
> 
> While this or a similar check might make sense, That should ideally be
> in the TTM shrinker helpers. And probably we should ask core mm for a
> proper indication whether this is indeed fragmentation-driven.
> 

Yes, moving this to a TTM shrinker helper—or even a core MM helper—makes
more sense. This is the best heuristic I could come up with based on
what is available in the core MM today. However, this is still not 100%
correct, as I don’t think ZONE_NORMAL is used on systems with less than
4GB of memory; instead, ZONE_DMA32 is used. This might get even worse
when considering Kconfig combonations. Asking the core MM via a helper
whether memory is fragmented is likely the best solution.

Matt

> Thanks,
> Thomas
> 
> 
> 
> >  	/* If we didn't wake before, try to do it now if needed. */
> >  	if (!runtime_pm)
> >  		runtime_pm = xe_shrinker_runtime_pm_get(shrinker,
> > true, 0, can_backup);