Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
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?


      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