From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: Matthew Auld <matthew.auld@intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: maarten.lankhorst@linux.intel.com Subject: Re: [PATCH v3 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume Date: Mon, 20 Sep 2021 13:05:06 +0200 [thread overview] Message-ID: <dad2ffb155fb971d454ebd469f252892357a88ab.camel@linux.intel.com> (raw) In-Reply-To: <01a1827d-ab6f-bd88-7291-dd68676c0eae@intel.com> On Mon, 2021-09-20 at 11:49 +0100, Matthew Auld wrote: > On 14/09/2021 20:31, Thomas Hellström wrote: > > Just evict unpinned objects to system. For pinned LMEM objects, > > make a backup system object and blit the contents to that. > > > > Backup is performed in three steps, > > 1: Opportunistically evict evictable objects using the gpu blitter. > > 2: After gt idle, evict evictable objects using the gpu blitter. > > This will > > be modified in an upcoming patch to backup pinned objects that are > > not used > > by the blitter itself. > > 3: Backup remaining pinned objects using memcpy. > > > > Also move uC suspend to after 2) to make sure we have a functional > > GuC > > during 2) if using GuC submission. > > > > v2: > > - Major refactor to make sure gem_exec_suspend@hang-SX subtests > > work, and > > suspend / resume works with a slightly modified GuC submission > > enabling > > patch series. > > > > v3: > > - Fix a potential use-after-free (Matthew Auld) > > - Use i915_gem_object_create_shmem() instead of > > i915_gem_object_create_region (Matthew Auld) > > - Minor simplifications (Matthew Auld) > > - Fix up kerneldoc for i195_ttm_restore_region(). > > - Final lmem_suspend() call moved to i915_gem_backup_suspend from > > i915_gem_suspend_late, since the latter gets called at driver > > unload > > and we don't unnecessarily want to run it at that time. > > > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> > > <snip> > > > + > > +static int i915_ttm_restore(struct i915_gem_apply_to_region > > *apply, > > + struct drm_i915_gem_object *obj) > > +{ > > + struct i915_gem_ttm_pm_apply *pm_apply = > > + container_of(apply, typeof(*pm_apply), base); > > + struct drm_i915_gem_object *backup = obj->ttm.backup; > > + struct ttm_buffer_object *backup_bo = > > i915_gem_to_ttm(backup); > > + struct ttm_operation_ctx ctx = {}; > > + int err; > > + > > + if (!backup) > > + return 0; > > + > > + if (!pm_apply->allow_gpu && (obj->flags & > > I915_BO_ALLOC_USER)) > > + return 0; > > Hmm, do we ever hit this? I would presume anything that userspace > directly allocated in lmem can be kicked out with > ttm_bo_validate(sys) > i.e backup == NULL? At this point, (before patch 6/6) I think we might do. Typical candidates are dma-buf objects that have become pinned on exporting, and perhaps framebuffers that are pinned, not sure they are unpinned before we back them up. But it might be that we should remove this after patch 6/6 where we require a special flag for early recovers using memcpy. /Thomas > > > + > > + err = i915_gem_object_lock(backup, apply->ww); > > + if (err) > > + return err; > > + > > + /* Content may have been swapped. */ > > + err = ttm_tt_populate(backup_bo->bdev, backup_bo->ttm, > > &ctx); > > + if (!err) { > > + err = i915_gem_obj_copy_ttm(obj, backup, pm_apply- > > >allow_gpu, > > + false); > > + GEM_WARN_ON(err); > > + > > + obj->ttm.backup = NULL; > > + err = 0; > > + } > > + > > + i915_gem_ww_unlock_single(backup); > > + > > + if (!err) > > + i915_gem_object_put(backup); > > + > > + return err; > > +} > > +
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: Matthew Auld <matthew.auld@intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: maarten.lankhorst@linux.intel.com Subject: Re: [Intel-gfx] [PATCH v3 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume Date: Mon, 20 Sep 2021 13:05:06 +0200 [thread overview] Message-ID: <dad2ffb155fb971d454ebd469f252892357a88ab.camel@linux.intel.com> (raw) In-Reply-To: <01a1827d-ab6f-bd88-7291-dd68676c0eae@intel.com> On Mon, 2021-09-20 at 11:49 +0100, Matthew Auld wrote: > On 14/09/2021 20:31, Thomas Hellström wrote: > > Just evict unpinned objects to system. For pinned LMEM objects, > > make a backup system object and blit the contents to that. > > > > Backup is performed in three steps, > > 1: Opportunistically evict evictable objects using the gpu blitter. > > 2: After gt idle, evict evictable objects using the gpu blitter. > > This will > > be modified in an upcoming patch to backup pinned objects that are > > not used > > by the blitter itself. > > 3: Backup remaining pinned objects using memcpy. > > > > Also move uC suspend to after 2) to make sure we have a functional > > GuC > > during 2) if using GuC submission. > > > > v2: > > - Major refactor to make sure gem_exec_suspend@hang-SX subtests > > work, and > > suspend / resume works with a slightly modified GuC submission > > enabling > > patch series. > > > > v3: > > - Fix a potential use-after-free (Matthew Auld) > > - Use i915_gem_object_create_shmem() instead of > > i915_gem_object_create_region (Matthew Auld) > > - Minor simplifications (Matthew Auld) > > - Fix up kerneldoc for i195_ttm_restore_region(). > > - Final lmem_suspend() call moved to i915_gem_backup_suspend from > > i915_gem_suspend_late, since the latter gets called at driver > > unload > > and we don't unnecessarily want to run it at that time. > > > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> > > <snip> > > > + > > +static int i915_ttm_restore(struct i915_gem_apply_to_region > > *apply, > > + struct drm_i915_gem_object *obj) > > +{ > > + struct i915_gem_ttm_pm_apply *pm_apply = > > + container_of(apply, typeof(*pm_apply), base); > > + struct drm_i915_gem_object *backup = obj->ttm.backup; > > + struct ttm_buffer_object *backup_bo = > > i915_gem_to_ttm(backup); > > + struct ttm_operation_ctx ctx = {}; > > + int err; > > + > > + if (!backup) > > + return 0; > > + > > + if (!pm_apply->allow_gpu && (obj->flags & > > I915_BO_ALLOC_USER)) > > + return 0; > > Hmm, do we ever hit this? I would presume anything that userspace > directly allocated in lmem can be kicked out with > ttm_bo_validate(sys) > i.e backup == NULL? At this point, (before patch 6/6) I think we might do. Typical candidates are dma-buf objects that have become pinned on exporting, and perhaps framebuffers that are pinned, not sure they are unpinned before we back them up. But it might be that we should remove this after patch 6/6 where we require a special flag for early recovers using memcpy. /Thomas > > > + > > + err = i915_gem_object_lock(backup, apply->ww); > > + if (err) > > + return err; > > + > > + /* Content may have been swapped. */ > > + err = ttm_tt_populate(backup_bo->bdev, backup_bo->ttm, > > &ctx); > > + if (!err) { > > + err = i915_gem_obj_copy_ttm(obj, backup, pm_apply- > > >allow_gpu, > > + false); > > + GEM_WARN_ON(err); > > + > > + obj->ttm.backup = NULL; > > + err = 0; > > + } > > + > > + i915_gem_ww_unlock_single(backup); > > + > > + if (!err) > > + i915_gem_object_put(backup); > > + > > + return err; > > +} > > +
next prev parent reply other threads:[~2021-09-20 11:05 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-14 19:31 [PATCH v3 0/6] drm/i915: Suspend / resume backup- and restore of LMEM Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-14 19:31 ` [PATCH v3 1/6] drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-16 10:17 ` Matthew Auld 2021-09-16 10:17 ` [Intel-gfx] " Matthew Auld 2021-09-14 19:31 ` [PATCH v3 2/6] drm/i915/gem: Implement a function to process all gem objects of a region Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-16 10:23 ` Matthew Auld 2021-09-16 10:23 ` [Intel-gfx] " Matthew Auld 2021-09-14 19:31 ` [PATCH v3 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-17 12:03 ` Matthew Auld 2021-09-17 12:03 ` [Intel-gfx] " Matthew Auld 2021-09-20 10:49 ` Matthew Auld 2021-09-20 10:49 ` [Intel-gfx] " Matthew Auld 2021-09-20 11:05 ` Thomas Hellström [this message] 2021-09-20 11:05 ` Thomas Hellström 2021-09-14 19:31 ` [PATCH v3 4/6] drm/i915/gt: Register the migrate contexts with their engines Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-20 9:53 ` Matthew Auld 2021-09-20 9:53 ` [Intel-gfx] " Matthew Auld 2021-09-14 19:31 ` [PATCH v3 5/6] drm/i915: Don't back up pinned LMEM context images and rings during suspend Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-20 9:57 ` Matthew Auld 2021-09-20 9:57 ` [Intel-gfx] " Matthew Auld 2021-09-14 19:31 ` [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover Thomas Hellström 2021-09-14 19:31 ` [Intel-gfx] " Thomas Hellström 2021-09-20 11:05 ` Matthew Auld 2021-09-20 11:05 ` [Intel-gfx] " Matthew Auld 2021-09-20 11:09 ` Thomas Hellström 2021-09-20 11:09 ` [Intel-gfx] " Thomas Hellström 2021-09-14 19:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Suspend / resume backup- and restore of LMEM. (rev4) Patchwork 2021-09-14 20:06 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-09-14 21:14 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-09-15 12:22 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Suspend / resume backup- and restore of LMEM. (rev5) Patchwork 2021-09-15 13:09 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
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=dad2ffb155fb971d454ebd469f252892357a88ab.camel@linux.intel.com \ --to=thomas.hellstrom@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=matthew.auld@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.