intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Patchwork <patchwork@emeril.freedesktop.org>
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: ✗ CI.checkpatch: warning for mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation (rev4)
Date: Wed, 06 May 2026 03:38:57 -0000	[thread overview]
Message-ID: <177803873762.41911.3713495655239749534@5ab824fced77> (raw)
In-Reply-To: <20260506033300.3534883-1-matthew.brost@intel.com>

== Series Details ==

Series: mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation (rev4)
URL   : https://patchwork.freedesktop.org/series/165329/
State : warning

== Summary ==

+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
c8c12e558adaef7a4d125d83b6e1f8824bc13b82
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit 04f4cebb6dc17a18e9241c5e434b66e9252c70ba
Author: Matthew Brost <matthew.brost@intel.com>
Date:   Tue May 5 20:33:00 2026 -0700

    drm/xe: Make use of shrink_control::opportunistic_compaction hint
    
    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.
    
    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.
    
    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.
    
    Order-0 and non-opportunistic reclaim behavior remain unchanged, so
    Xe backup reclaim still participates normally during genuine memory
    pressure.
    
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Dave Chinner <david@fromorbit.com>
    Cc: Qi Zheng <zhengqi.arch@bytedance.com>
    Cc: Roman Gushchin <roman.gushchin@linux.dev>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: David Hildenbrand <david@kernel.org>
    Cc: Lorenzo Stoakes <ljs@kernel.org>
    Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com>
    Cc: Vlastimil Babka <vbabka@kernel.org>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Shakeel Butt <shakeel.butt@linux.dev>
    Cc: Kairui Song <kasong@tencent.com>
    Cc: Barry Song <baohua@kernel.org>
    Cc: Axel Rasmussen <axelrasmussen@google.com>
    Cc: Yuanchu Xie <yuanchu@google.com>
    Cc: Wei Xu <weixugc@google.com>
    Cc: linux-mm@kvack.org
    Cc: linux-kernel@vger.kernel.org
    Assisted-by: Claude:claude-opus-4.6
    Signed-off-by: Matthew Brost <matthew.brost@intel.com>
+ /mt/dim checkpatch 2046bd160271a39a4abff3d0033500d7a669a9f1 drm-intel
9559a0f37256 mm: Wire up order in shrink_control
-:79: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#79: FILE: mm/shrinker.c:470:
+static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid, s8 order,
 			struct mem_cgroup *memcg, int priority)

-:96: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#96: FILE: mm/shrinker.c:592:
+static unsigned long shrink_slab_memcg(gfp_t gfp_mask, int nid, s8 order,
 			struct mem_cgroup *memcg, int priority)

total: 0 errors, 0 warnings, 2 checks, 99 lines checked
b4812e60e3dc mm: Introduce opportunistic_compaction concept to vmscan and shrinkers
805f4d89d6fa drm/ttm: Issue direct reclaim at beneficial_order
2e4dd3a8a32f drm/xe: Set TTM device beneficial_order to 9 (2M)
04f4cebb6dc1 drm/xe: Make use of shrink_control::opportunistic_compaction hint



  parent reply	other threads:[~2026-05-06  3:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  3:32 [PATCH v5 0/5] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation Matthew Brost
2026-05-06  3:32 ` [PATCH v5 1/5] mm: Wire up order in shrink_control Matthew Brost
2026-05-06  3:32 ` [PATCH v5 2/5] mm: Introduce opportunistic_compaction concept to vmscan and shrinkers Matthew Brost
2026-05-06  3:32 ` [PATCH v5 3/5] drm/ttm: Issue direct reclaim at beneficial_order Matthew Brost
2026-05-06  3:32 ` [PATCH v5 4/5] drm/xe: Set TTM device beneficial_order to 9 (2M) Matthew Brost
2026-05-07 11:18   ` Thomas Hellström
2026-05-06  3:33 ` [PATCH v5 5/5] drm/xe: Make use of shrink_control::opportunistic_compaction hint Matthew Brost
2026-05-06 14:38   ` Thomas Hellström
2026-05-06  3:38 ` Patchwork [this message]
2026-05-06  3:40 ` ✓ CI.KUnit: success for mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation (rev4) Patchwork
2026-05-09  0:03 ` [PATCH v5 0/5] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation Andrew Morton
2026-05-09  2:31   ` Qi Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=177803873762.41911.3713495655239749534@5ab824fced77 \
    --to=patchwork@emeril.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).