From: Matthew Auld <matthew.auld@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH i-g-t] tests/intel/xe_bo_shrink: Add a user-space shrinker test
Date: Thu, 22 Oct 2026 12:22:11 +0100 [thread overview]
Message-ID: <98f71c1f-bb91-431e-8dbe-c3cae049eeba@intel.com> (raw)
In-Reply-To: <20261021123315.10033-1-thomas.hellstrom@linux.intel.com>
On 21/10/2026 13:33, Thomas Hellström wrote:
> Add a user-space counterpart of the xe_bo_shrink kunit test, now that
> user-space can mark buffer objects purgeable using the madvise IOCTL.
>
> The test creates 64 MiB system buffer objects corresponding to twice
> the amount of free system memory, fills them with pseudo-random data
> through CPU mappings that are kept alive until readback, and verifies
> the contents after the overcommit has forced the shrinker to back up
> or purge them. As in the kunit test, the share of the memory that
> doesn't fit in free RAM and swap is marked purgeable (DONTNEED) and
> allocated first. Purgeable objects are only verified if found retained
> when marked WILLNEED again; purged objects are never accessed.
>
> Subtests:
> - shrink: The kunit test equivalent.
> - purge: Ignore swap space when sizing the purgeable share, so that
> the shrinker needs to purge rather than swap.
> - shrink-fault-inject: Enable TTM backup / restore fault injection
> through debugfs, if available, making the shrinker back up only part
> of the objects and making backup and restore of individual pages
> fail. The number of injected faults is checked to be non-zero.
> - *-blit: Rather than restoring objects by CPU faults, restore them
> through a GPU bind and read them back by a MEM_COPY blit to a dummy
> object in a separate VM. On discrete devices, objects are created
> with system and VRAM placements, prefetched to system memory on
> creation and prefetched to VRAM before the copy, so that they are
> restored by the migration to VRAM.
Do we use any compression here on igpu? IIRC that is still a pretty big
test gap. We have the equivalent for VRAM via the CCS evict test, but I
don't think we have anything for igpu + CCS via shrinker. Maybe the
kunit does it, but IIUC that is never run in CI?
> - *-private: Create the objects private to the test VM rather than as
> external objects.
> - *-fast: Allocate at most the free system memory, half of it
> purgeable, capped to 8 GiB purgeable and 8 GiB non-purgeable, and
> shrink using drop_caches rather than memory overcommit.
>
> The non-fast subtests are slow and require a substantial amount of
> swap space for meaningful coverage, so block them in CI and run only
> the fast subtests.
Were there any issues with the test itself getting killed? I seem to
vaguely remember something like that from the i915 shrinker test. Or is
that not a concern here?
prev parent reply other threads:[~2026-10-22 11:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 12:33 [PATCH i-g-t] tests/intel/xe_bo_shrink: Add a user-space shrinker test Thomas Hellström
2026-10-21 15:03 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-10-21 19:09 ` [PATCH i-g-t] " Matthew Brost
2026-10-22 11:22 ` Matthew Auld [this message]
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=98f71c1f-bb91-431e-8dbe-c3cae049eeba@intel.com \
--to=matthew.auld@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=thomas.hellstrom@linux.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