From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1841D44D682 for ; Wed, 6 May 2026 14:38:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778078342; cv=none; b=QJFB00k29jxGT7mZI78SMx/5CjAxRnkcqxNj513LlUnfrz76X8rkN/kNTqQ3t7+aMkhAuGAwX6aOsefh6IuHppOZkFojXI/nSH4GV5Kw2IKwHpC/67f7Y4gua82wZjLmuv/P4o+h8Dm2PZ1X4k3YIg4vOpYWnF2dDsKmgok3Clo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778078342; c=relaxed/simple; bh=3cyqpWM4hY2WHFw6kor77wf8w5w1B47aBYbK7oUub5M=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Q6Hal+lV/gmnQNZL0jsyp+qbZgwmAYjuK+AT6OfTROmndxAqluYX5TVDr8hrtIkPkuDQFMwSuECV98cJnl2vVJk6gycnRvdFIDGorSek8iTZuhCwY/U8AG4RwFt+idQMJ+JabLztTq9t4KgIrmDgEN16rOgMvdsJgi51LK8ePRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IXGDlvEQ; arc=none smtp.client-ip=198.175.65.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="IXGDlvEQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778078339; x=1809614339; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=3cyqpWM4hY2WHFw6kor77wf8w5w1B47aBYbK7oUub5M=; b=IXGDlvEQKJPDnqRwA5AoDysOuKIa4avhx18Ga6mfCtI9uHSAmjXC8P7W 1CgUeJyjJI3PPEzsjpyZruJEWRjjtQeecXozEyl2mPOEIumNbkcFaM89H 2ynYAmmfzX8NRDOYG69Kgpk6l/O/FzFNA3M0j2OLbgslDoIsWyvBQIfri rRNnmwpS1/ynO/pkL6YIkgqBhltDTJNZaeuw6KSuhuIp+/6xhY21gbKKl 1QmHF9Wt1QANh67jzBncijGYSG5R0M4NyrpHDdId4zHxiNtKeYxsfvesq gvePxnEGqk1tKD1zoj+oc4IPG8kh5j1l8VT/MWIjpcSQp6Xduoy6jDiDj g==; X-CSE-ConnectionGUID: eFu4742gRbSSx4Lx/PBPSw== X-CSE-MsgGUID: V0i6lIXpTPWS3U+MqOhu+w== X-IronPort-AV: E=McAfee;i="6800,10657,11778"; a="101685854" X-IronPort-AV: E=Sophos;i="6.23,219,1770624000"; d="scan'208";a="101685854" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2026 07:38:57 -0700 X-CSE-ConnectionGUID: MO97WVf1RiKlPmy703qAnA== X-CSE-MsgGUID: +9Zcu98LQayImxZ/dfr1kg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,219,1770624000"; d="scan'208";a="236074423" Received: from kniemiec-mobl1.ger.corp.intel.com (HELO [10.245.244.213]) ([10.245.244.213]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2026 07:38:52 -0700 Message-ID: Subject: Re: [PATCH v5 5/5] drm/xe: Make use of shrink_control::opportunistic_compaction hint From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Matthew Brost , intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: Andrew Morton , Dave Chinner , Qi Zheng , Roman Gushchin , Muchun Song , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Johannes Weiner , Shakeel Butt , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Wed, 06 May 2026 16:38:48 +0200 In-Reply-To: <20260506033300.3534883-6-matthew.brost@intel.com> References: <20260506033300.3534883-1-matthew.brost@intel.com> <20260506033300.3534883-6-matthew.brost@intel.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-05-05 at 20:33 -0700, Matthew Brost wrote: > Xe/TTM backup reclaim can be extremely expensive under fragmentation > pressure as reclaim may migrate or destroy actively used GPU working > sets despite the system still having substantial free memory > available. >=20 > Under high-order opportunistic reclaim, repeatedly backing up GPU > memory can lead to reclaim/rebind ping-pong behavior where active GPU > working sets are continuously torn down and reconstructed without > materially improving allocation success. >=20 > Use the new shrink_control::opportunistic_compaction hint to avoid Xe > backup reclaim during fragmentation-driven high-order reclaim > attempts. > In this mode the shrinker skips advertising backup-backed reclaimable > memory and avoids initiating backup operations entirely. >=20 > Order-0 and non-opportunistic reclaim behavior remain unchanged, so > Xe backup reclaim still participates normally during genuine memory > pressure. >=20 > Cc: Andrew Morton > Cc: Dave Chinner > Cc: Qi Zheng > Cc: Roman Gushchin > Cc: Muchun Song > Cc: David Hildenbrand > Cc: Lorenzo Stoakes > Cc: "Liam R. Howlett" > Cc: Vlastimil Babka > Cc: Mike Rapoport > Cc: Suren Baghdasaryan > Cc: Michal Hocko > Cc: Johannes Weiner > Cc: Shakeel Butt > Cc: Kairui Song > Cc: Barry Song > Cc: Axel Rasmussen > Cc: Yuanchu Xie > Cc: Wei Xu > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > Assisted-by: Claude:claude-opus-4.6 > Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellstr=C3=B6m > --- > =C2=A0drivers/gpu/drm/xe/xe_shrinker.c | 20 +++++++++++++++++--- > =C2=A01 file changed, 17 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/gpu/drm/xe/xe_shrinker.c > b/drivers/gpu/drm/xe/xe_shrinker.c > index 83374cd57660..4646b0f5b82b 100644 > --- a/drivers/gpu/drm/xe/xe_shrinker.c > +++ b/drivers/gpu/drm/xe/xe_shrinker.c > @@ -139,10 +139,17 @@ static unsigned long > =C2=A0xe_shrinker_count(struct shrinker *shrink, struct shrink_control > *sc) > =C2=A0{ > =C2=A0 struct xe_shrinker *shrinker =3D to_xe_shrinker(shrink); > - unsigned long num_pages; > + unsigned long num_pages =3D 0; > =C2=A0 bool can_backup =3D !!(sc->gfp_mask & __GFP_FS); > =C2=A0 > - num_pages =3D ttm_backup_bytes_avail() >> PAGE_SHIFT; > + /* > + * Skip accounting backup-able pages when this is an > opportunistic > + * high-order pass: TTM backup work shrinks at native page > granularity > + * and is unlikely to produce the contiguous block the > caller wants, > + * so don't advertise it as reclaimable for this hint. > + */ > + if (!sc->order || !sc->opportunistic_compaction) > + num_pages =3D ttm_backup_bytes_avail() >> PAGE_SHIFT; > =C2=A0 read_lock(&shrinker->lock); > =C2=A0 > =C2=A0 if (can_backup) > @@ -233,7 +240,14 @@ static unsigned long xe_shrinker_scan(struct > shrinker *shrink, struct shrink_con > =C2=A0 } > =C2=A0 > =C2=A0 sc->nr_scanned =3D nr_scanned; > - if (nr_scanned >=3D nr_to_scan || !can_backup) > + /* > + * Stop after the purge pass for opportunistic high-order > reclaim: > + * the subsequent backup/writeback pass works at native page > order > + * and is unlikely to free a contiguous high-order block, so > doing > + * it here would just churn working sets for no compaction > benefit. > + */ > + if (nr_scanned >=3D nr_to_scan || !can_backup || > + =C2=A0=C2=A0=C2=A0 (sc->order && sc->opportunistic_compaction)) > =C2=A0 goto out; > =C2=A0 > =C2=A0 /* If we didn't wake before, try to do it now if needed. */