From: "Christian König" <christian.koenig@amd.com> To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v4 10/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping Date: Wed, 26 May 2021 15:26:07 +0200 [thread overview] Message-ID: <9f49eb8e-8ec5-cb24-0ce1-3e63272628e8@amd.com> (raw) In-Reply-To: <20210526113259.1661914-11-thomas.hellstrom@linux.intel.com> Am 26.05.21 um 13:32 schrieb Thomas Hellström: > We are calling the eviction_valuable driver callback at eviction time to > determine whether we actually can evict a buffer object. > The upcoming i915 TTM backend needs the same functionality for swapout, > and that might actually be beneficial to other drivers as well. > > Add an eviction_valuable call also in the swapout path. Try to keep the > current behaviour for all drivers by returning true if the buffer object > is already in the TTM_PL_SYSTEM placement. We change behaviour for the > case where a buffer object is in a TT backed placement when swapped out, > in which case the drivers normal eviction_valuable path is run. > > Finally make sure we don't try to swapout a bo that was recently purged > and therefore unpopulated. > > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Christian König <christian.koenig@amd.com> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> > --- > v3: > - Don't export ttm_tt_unpopulate > - Fix confusion reading the locked pointer instead of the value > pointed to in ttm_bo_evict_swapout_allowable (Reported by > Maarten Lankhorst) > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++ > drivers/gpu/drm/ttm/ttm_bo.c | 43 ++++++++++++++++--------- > drivers/gpu/drm/ttm/ttm_tt.c | 3 ++ > 3 files changed, 34 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 3bc3aebfef7c..45d194bffc3f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -1348,6 +1348,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, > struct dma_fence *f; > int i; > > + /* Swapout? */ > + if (bo->mem.mem_type == TTM_PL_SYSTEM) > + return true; > + > if (bo->type == ttm_bo_type_kernel && > !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo))) > return false; > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index be0406466460..1b2d062266ed 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, > bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, > const struct ttm_place *place) > { > + dma_resv_assert_held(bo->base.resv); > + if (bo->mem.mem_type == TTM_PL_SYSTEM) > + return true; > + > /* Don't evict this BO if it's outside of the > * requested placement range > */ > @@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable); > * b. Otherwise, trylock it. > */ > static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, > - struct ttm_operation_ctx *ctx, bool *locked, bool *busy) > + struct ttm_operation_ctx *ctx, > + const struct ttm_place *place, > + bool *locked, bool *busy) > { > bool ret = false; > > @@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, > *busy = !ret; > } > > + if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) { > + ret = false; > + if (*locked) { > + dma_resv_unlock(bo->base.resv); > + *locked = false; > + } > + } > + > return ret; > } > > @@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev, > list_for_each_entry(bo, &man->lru[i], lru) { > bool busy; > > - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, > - &busy)) { > + if (!ttm_bo_evict_swapout_allowable(bo, ctx, place, > + &locked, &busy)) { > if (busy && !busy_bo && ticket != > dma_resv_locking_ctx(bo->base.resv)) > busy_bo = bo; > continue; > } > > - if (place && !bdev->funcs->eviction_valuable(bo, > - place)) { > - if (locked) > - dma_resv_unlock(bo->base.resv); > - continue; > - } > if (!ttm_bo_get_unless_zero(bo)) { > if (locked) > dma_resv_unlock(bo->base.resv); > @@ -1140,10 +1148,18 @@ EXPORT_SYMBOL(ttm_bo_wait); > int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, > gfp_t gfp_flags) > { > + struct ttm_place place = {}; > bool locked; > int ret; > > - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL)) > + /* > + * While the bo may already reside in SYSTEM placement, set > + * SYSTEM as new placement to cover also the move further below. > + * The driver may use the fact that we're moving from SYSTEM > + * as an indication that we're about to swap out. > + */ > + place.mem_type = TTM_PL_SYSTEM; > + if (!ttm_bo_evict_swapout_allowable(bo, ctx, &place, &locked, NULL)) > return -EBUSY; > > if (!ttm_bo_get_unless_zero(bo)) { > @@ -1168,12 +1184,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, > if (bo->mem.mem_type != TTM_PL_SYSTEM) { > struct ttm_operation_ctx ctx = { false, false }; > struct ttm_resource evict_mem; > - struct ttm_place place, hop; > - > - memset(&place, 0, sizeof(place)); > - memset(&hop, 0, sizeof(hop)); > - > - place.mem_type = TTM_PL_SYSTEM; > + struct ttm_place hop = {}; I would stick with memset because of the padding reasons. > > ret = ttm_resource_alloc(bo, &place, &evict_mem); > if (unlikely(ret)) > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c > index 913b330a234b..d9793cbb6d13 100644 > --- a/drivers/gpu/drm/ttm/ttm_tt.c > +++ b/drivers/gpu/drm/ttm/ttm_tt.c > @@ -263,6 +263,9 @@ int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm, > struct page *to_page; > int i, ret; > > + if (!ttm_tt_is_populated(ttm)) > + return 0; > + This here is just because of a bug in the higher level function. I've just pushed the fix for that to drm-misc-fixes, so maybe drop that here as soon as this is backmerged. Apart from that patch looks good to me. Christian. > swap_storage = shmem_file_setup("ttm swap", size, 0); > if (IS_ERR(swap_storage)) { > pr_err("Failed allocating swap storage\n");
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com> To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v4 10/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping Date: Wed, 26 May 2021 15:26:07 +0200 [thread overview] Message-ID: <9f49eb8e-8ec5-cb24-0ce1-3e63272628e8@amd.com> (raw) In-Reply-To: <20210526113259.1661914-11-thomas.hellstrom@linux.intel.com> Am 26.05.21 um 13:32 schrieb Thomas Hellström: > We are calling the eviction_valuable driver callback at eviction time to > determine whether we actually can evict a buffer object. > The upcoming i915 TTM backend needs the same functionality for swapout, > and that might actually be beneficial to other drivers as well. > > Add an eviction_valuable call also in the swapout path. Try to keep the > current behaviour for all drivers by returning true if the buffer object > is already in the TTM_PL_SYSTEM placement. We change behaviour for the > case where a buffer object is in a TT backed placement when swapped out, > in which case the drivers normal eviction_valuable path is run. > > Finally make sure we don't try to swapout a bo that was recently purged > and therefore unpopulated. > > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Christian König <christian.koenig@amd.com> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> > --- > v3: > - Don't export ttm_tt_unpopulate > - Fix confusion reading the locked pointer instead of the value > pointed to in ttm_bo_evict_swapout_allowable (Reported by > Maarten Lankhorst) > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +++ > drivers/gpu/drm/ttm/ttm_bo.c | 43 ++++++++++++++++--------- > drivers/gpu/drm/ttm/ttm_tt.c | 3 ++ > 3 files changed, 34 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 3bc3aebfef7c..45d194bffc3f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -1348,6 +1348,10 @@ static bool amdgpu_ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, > struct dma_fence *f; > int i; > > + /* Swapout? */ > + if (bo->mem.mem_type == TTM_PL_SYSTEM) > + return true; > + > if (bo->type == ttm_bo_type_kernel && > !amdgpu_vm_evictable(ttm_to_amdgpu_bo(bo))) > return false; > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index be0406466460..1b2d062266ed 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -536,6 +536,10 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, > bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, > const struct ttm_place *place) > { > + dma_resv_assert_held(bo->base.resv); > + if (bo->mem.mem_type == TTM_PL_SYSTEM) > + return true; > + > /* Don't evict this BO if it's outside of the > * requested placement range > */ > @@ -558,7 +562,9 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable); > * b. Otherwise, trylock it. > */ > static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, > - struct ttm_operation_ctx *ctx, bool *locked, bool *busy) > + struct ttm_operation_ctx *ctx, > + const struct ttm_place *place, > + bool *locked, bool *busy) > { > bool ret = false; > > @@ -576,6 +582,14 @@ static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo, > *busy = !ret; > } > > + if (ret && place && !bo->bdev->funcs->eviction_valuable(bo, place)) { > + ret = false; > + if (*locked) { > + dma_resv_unlock(bo->base.resv); > + *locked = false; > + } > + } > + > return ret; > } > > @@ -630,20 +644,14 @@ int ttm_mem_evict_first(struct ttm_device *bdev, > list_for_each_entry(bo, &man->lru[i], lru) { > bool busy; > > - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, > - &busy)) { > + if (!ttm_bo_evict_swapout_allowable(bo, ctx, place, > + &locked, &busy)) { > if (busy && !busy_bo && ticket != > dma_resv_locking_ctx(bo->base.resv)) > busy_bo = bo; > continue; > } > > - if (place && !bdev->funcs->eviction_valuable(bo, > - place)) { > - if (locked) > - dma_resv_unlock(bo->base.resv); > - continue; > - } > if (!ttm_bo_get_unless_zero(bo)) { > if (locked) > dma_resv_unlock(bo->base.resv); > @@ -1140,10 +1148,18 @@ EXPORT_SYMBOL(ttm_bo_wait); > int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, > gfp_t gfp_flags) > { > + struct ttm_place place = {}; > bool locked; > int ret; > > - if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL)) > + /* > + * While the bo may already reside in SYSTEM placement, set > + * SYSTEM as new placement to cover also the move further below. > + * The driver may use the fact that we're moving from SYSTEM > + * as an indication that we're about to swap out. > + */ > + place.mem_type = TTM_PL_SYSTEM; > + if (!ttm_bo_evict_swapout_allowable(bo, ctx, &place, &locked, NULL)) > return -EBUSY; > > if (!ttm_bo_get_unless_zero(bo)) { > @@ -1168,12 +1184,7 @@ int ttm_bo_swapout(struct ttm_buffer_object *bo, struct ttm_operation_ctx *ctx, > if (bo->mem.mem_type != TTM_PL_SYSTEM) { > struct ttm_operation_ctx ctx = { false, false }; > struct ttm_resource evict_mem; > - struct ttm_place place, hop; > - > - memset(&place, 0, sizeof(place)); > - memset(&hop, 0, sizeof(hop)); > - > - place.mem_type = TTM_PL_SYSTEM; > + struct ttm_place hop = {}; I would stick with memset because of the padding reasons. > > ret = ttm_resource_alloc(bo, &place, &evict_mem); > if (unlikely(ret)) > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c > index 913b330a234b..d9793cbb6d13 100644 > --- a/drivers/gpu/drm/ttm/ttm_tt.c > +++ b/drivers/gpu/drm/ttm/ttm_tt.c > @@ -263,6 +263,9 @@ int ttm_tt_swapout(struct ttm_device *bdev, struct ttm_tt *ttm, > struct page *to_page; > int i, ret; > > + if (!ttm_tt_is_populated(ttm)) > + return 0; > + This here is just because of a bug in the higher level function. I've just pushed the fix for that to drm-misc-fixes, so maybe drop that here as soon as this is backmerged. Apart from that patch looks good to me. Christian. > swap_storage = shmem_file_setup("ttm swap", size, 0); > if (IS_ERR(swap_storage)) { > pr_err("Failed allocating swap storage\n"); _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-05-26 13:26 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-26 11:32 [PATCH v4 00/15] drm/i915: Move LMEM (VRAM) management over to TTM Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 01/15] drm/i915: Untangle the vma pages_mutex Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 02/15] drm/i915: Don't free shared locks while shared Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 03/15] drm/i915: Fix i915_sg_page_sizes to record dma segments rather than physical pages Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 04/15] drm/i915/ttm Initialize the ttm device and memory managers Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 05/15] drm/i915/ttm: Embed a ttm buffer object in the i915 gem object Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 06/15] drm/ttm: Add a generic TTM memcpy move for page-based iomem Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 07/15] drm, drm/i915: Move the memcpy_from_wc functionality to core drm Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 14:27 ` Christian König 2021-05-26 14:27 ` [Intel-gfx] " Christian König 2021-05-26 11:32 ` [PATCH v4 08/15] drm/ttm: Use drm_memcpy_from_wc_dbm for TTM bo moves Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 09/15] drm/ttm: Document and optimize ttm_bo_pipeline_gutting() Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 14:32 ` Christian König 2021-05-26 14:32 ` [Intel-gfx] " Christian König 2021-05-26 11:32 ` [PATCH v4 10/15] drm/ttm, drm/amdgpu: Allow the driver some control over swapping Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 13:26 ` Christian König [this message] 2021-05-26 13:26 ` Christian König 2021-05-27 7:33 ` Thomas Hellström (Intel) 2021-05-27 7:33 ` [Intel-gfx] " Thomas Hellström (Intel) 2021-05-27 12:36 ` Christian König 2021-05-27 12:36 ` [Intel-gfx] " Christian König 2021-05-27 13:52 ` Thomas Hellström 2021-05-27 13:52 ` [Intel-gfx] " Thomas Hellström 2021-05-27 14:21 ` Thomas Hellström 2021-05-27 14:21 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 11/15] drm/i915/ttm: Introduce a TTM i915 gem object backend Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 12/15] drm/i915/lmem: Verify checks for lmem residency Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 11:32 ` [PATCH v4 13/15] drm/i915: Disable mmap ioctl for gen12+ Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 17:28 ` Thomas Hellström (Intel) 2021-05-26 17:28 ` [Intel-gfx] " Thomas Hellström (Intel) 2021-05-26 11:32 ` [PATCH v4 14/15] drm/vma: Add a driver_private member to vma_node Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-27 8:16 ` Thomas Hellström (Intel) 2021-05-27 8:16 ` [Intel-gfx] " Thomas Hellström (Intel) 2021-05-26 11:32 ` [PATCH v4 15/15] drm/i915: Use ttm mmap handling for ttm bo's Thomas Hellström 2021-05-26 11:32 ` [Intel-gfx] " Thomas Hellström 2021-05-26 17:40 ` Thomas Hellström 2021-05-26 17:40 ` [Intel-gfx] " Thomas Hellström 2021-05-27 11:11 ` Maarten Lankhorst 2021-05-27 11:11 ` [Intel-gfx] " Maarten Lankhorst 2021-05-26 16:20 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Move LMEM (VRAM) management over to TTM (rev4) Patchwork 2021-05-26 16:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2021-05-26 16:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-05-27 1:57 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=9f49eb8e-8ec5-cb24-0ce1-3e63272628e8@amd.com \ --to=christian.koenig@amd.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --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: 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.