From: Matthew Brost <matthew.brost@intel.com>
To: Kenneth Crudup <kenny@panix.com>
Cc: airlied@gmail.com, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: PATCH v4 0/6] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation
Date: Fri, 1 May 2026 14:10:07 -0700 [thread overview]
Message-ID: <afUWr74J1OVdcwGZ@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <1bc0b1a7-a01f-4dc2-ad7a-3a05f975331e@panix.com>
On Fri, May 01, 2026 at 01:05:57PM -0700, Kenneth Crudup wrote:
>
> On 5/1/26 13:00, Matthew Brost wrote:
>
> > So is this 7.1-rc1? It looks like new feature to 7.1 added by Dave [1] and
> > something look off here. Thanks for pointing this out.
>
> Yeah. I grab his master branch daily (as of 6fe0be6dc7fa RN).
>
> Is this a "shoot the messenger" thing? IOW, is the reporting off, or is the
I don't think I'm firing any shots.
> memory usage really that high?
I've been able to recreate this. It looks like accounting is correct
until the Xe shrinker runs - every time it kicks in GPUActive grows and
will not reduce past some new floor value. It looks like an accounting
bug in TTM or Xe (?).
Here is my output on a 8G PTL where I have intentionally triggered
shrinker to evict at least 23875 BOs (most likey quite few more but this
what I easily see in dmesg) after closing everything on desktop.
cat /proc/meminfo | grep GPU; cat /proc/buddyinfo;
GPUActive: 13100036 kB
GPUReclaim: 152 kB
Node 0, zone DMA 0 1 0 0 0 0 0 0 1 1 3
Node 0, zone DMA32 2320 1882 1523 1238 980 740 482 275 114 88 205
Node 0, zone Normal 9751 9343 6466 4237 2703 1162 805 420 191 145 289
Let me spend a bit of time here to see if I figure out where the
accounting goes wrong.
Matt
>
> (BTW, those are in 30-second intervals)
>
> > > ----
> > > 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
> > > ----
>
> -K
>
> --
> Kenneth R. Crudup / Sr. SW Engineer, Scott County Consulting, Orange County
> CA
>
next prev parent reply other threads:[~2026-05-01 21:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 19:18 [PATCH v4 0/6] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation Matthew Brost
2026-04-30 19:18 ` [PATCH v4 1/6] mm: Wire up order in shrink_control Matthew Brost
2026-04-30 19:18 ` [PATCH v4 2/6] mm: Introduce zone_maybe_fragmented_in_shrinker() Matthew Brost
2026-05-01 0:50 ` Santa, Carlos
2026-05-01 19:08 ` PATCH v4 0/6] mm, drm/ttm, drm/xe: Avoid reclaim/eviction loops under fragmentation Kenneth Crudup
2026-05-01 20:00 ` Matthew Brost
2026-05-01 20:05 ` Kenneth Crudup
2026-05-01 21:10 ` Matthew Brost [this message]
2026-05-01 22:33 ` Matthew Brost
2026-04-30 23:01 ` [PATCH " Andrew Morton
2026-05-01 6:28 ` Matthew Brost
2026-05-01 12:51 ` Andrew Morton
2026-05-01 1:42 ` Dave Chinner
2026-05-01 7:09 ` Matthew Brost
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=afUWr74J1OVdcwGZ@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=Liam.Howlett@oracle.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=kenny@panix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=vbabka@kernel.org \
/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