From: Matthew Brost <matthew.brost@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"Somalapuram Amaranath" <Amaranath.Somalapuram@amd.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 05/12] drm/ttm: Provide a generic LRU walker helper
Date: Tue, 18 Jun 2024 22:11:17 +0000 [thread overview]
Message-ID: <ZnIGBea3S5fquc32@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <20240618071820.130917-6-thomas.hellstrom@linux.intel.com>
On Tue, Jun 18, 2024 at 09:18:13AM +0200, Thomas Hellström wrote:
Replying to correct version...
> Provide a generic LRU walker in TTM, in the spirit of drm_gem_lru_scan()
> but building on the restartable TTM LRU functionality.
>
> The LRU walker optionally supports locking objects as part of
> a ww mutex locking transaction, to mimic to some extent the
> current functionality in ttm. However any -EDEADLK return
> is converted to -ENOMEM, so that the driver will need to back
> off and possibly retry without being able to keep the
> ticket.
>
Wouldn't the backoff be unlock everything but keep the ticket?
> v3:
> - Move the helper to core ttm.
> - Remove the drm_exec usage from it for now, it will be
> reintroduced later in the series.
> v4:
> - Handle the -EALREADY case if ticketlocking.
>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: <dri-devel@lists.freedesktop.org>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 145 ++++++++++++++++++++++++++++++
> include/drm/ttm/ttm_bo.h | 32 +++++++
> 2 files changed, 177 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 0b3f4267130c..45fcaf6f8644 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -768,3 +768,148 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
> ttm_tt_destroy(bo->bdev, ttm);
> return ret;
> }
> +
> +static bool ttm_lru_walk_trylock(struct ttm_lru_walk *walk,
> + struct ttm_buffer_object *bo,
> + bool *needs_unlock)
> +{
> + struct ttm_operation_ctx *ctx = walk->ctx;
> +
> + *needs_unlock = false;
> +
> + if (dma_resv_trylock(bo->base.resv)) {
> + *needs_unlock = true;
> + return true;
> + }
> +
> + if (bo->base.resv == ctx->resv && ctx->allow_res_evict) {
> + dma_resv_assert_held(bo->base.resv);
> + return true;
> + }
> +i
Any reason this is done after the try lock? Just kinda goofy as if this
statement is true the dma_resv_trylock will always fail.
> + return false;
> +}
> +
> +static int ttm_lru_walk_ticketlock(struct ttm_lru_walk *walk,
> + struct ttm_buffer_object *bo,
> + bool *needs_unlock)
> +{
> + struct dma_resv *resv = bo->base.resv;
> + int ret;
> +
I suppose we don't have asserts here like in Xe but if we did,
assert(walk->ticket)?
> + if (walk->ctx->interruptible)
> + ret = dma_resv_lock_interruptible(resv, walk->ticket);
> + else
> + ret = dma_resv_lock(resv, walk->ticket);
> +
> + if (!ret) {
> + *needs_unlock = true;
> + /* Only a single ticketlock per loop. */
> + walk->ticket = NULL;
Can you explain this a bit more? I see that once the walk->ticket is set
to NULL this function will not be called again (i.e. only try locking
will be used). I want to understand the reasoning for this.
It might be helpful for a more lengthly explaination in the comments of
the code too.
> + } else if (ret == -EDEADLK) {
> + /* Caller needs to exit the ww transaction. */
> + ret = -ENOSPC;
The commit message says -ENOMEM.
> + }
> +
> + return ret;
> +}
> +
> +static void ttm_lru_walk_unlock(struct ttm_buffer_object *bo, bool locked)
> +{
> + if (locked)
> + dma_resv_unlock(bo->base.resv);
> +}
> +
> +/**
> + * ttm_lru_walk_for_evict() - Perform a LRU list walk, with actions taken on
> + * valid items.
> + * @walk: describe the walks and actions taken
> + * @bdev: The TTM device.
> + * @man: The struct ttm_resource manager whose LRU lists we're walking.
> + * @target: The end condition for the walk.
> + *
> + * The LRU lists of @man are walk, and for each struct ttm_resource encountered,
> + * the corresponding ttm_buffer_object is locked and taken a reference on, and
> + * the LRU lock is dropped. the LRU lock may be dropped before locking and, in
> + * that case, it's verified that the item actually remains on the LRU list after
> + * the lock, and that the buffer object didn't switch resource in between.
> + *
> + * With a locked object, the actions indicated by @walk->process_bo are
> + * performed, and after that, the bo is unlocked, the refcount dropped and the
> + * next struct ttm_resource is processed. Here, the walker relies on
> + * TTM's restartable LRU list implementation.
> + *
> + * Typically @walk->process_bo() would return the number of pages evicted,
> + * swapped or shrunken, so that when the total exceeds @target, or when the
> + * LRU list has been walked in full, iteration is terminated. It's also terminated
> + * on error. Note that the definition of @target is done by the caller, it
> + * could have a different meaning than the number of pages.
> + *
> + * Note that the way dma_resv individualization is done, locking needs to be done
> + * either with the LRU lock held (trylocking only) or with a reference on the
> + * object.
> + *
> + * Return: The progress made towards target or negative error code on error.
> + */
> +long ttm_lru_walk_for_evict(struct ttm_lru_walk *walk, struct ttm_device *bdev,
> + struct ttm_resource_manager *man, long target)
> +{
> + struct ttm_resource_cursor cursor;
> + struct ttm_resource *res;
> + long sofar = 0;
s/sofar/evicted?
> + long lret;
> +
> + spin_lock(&bdev->lru_lock);
> + ttm_resource_manager_for_each_res(man, &cursor, res) {
> + struct ttm_buffer_object *bo = res->bo;
> + bool bo_needs_unlock = false;
> + bool bo_locked = false;
> + int mem_type;
> +
> + if (!bo || bo->resource != res)
> + continue;
> +
> + if (ttm_lru_walk_trylock(walk, bo, &bo_needs_unlock))
> + bo_locked = true;
> + else if ((!walk->ticket) || walk->ctx->no_wait_gpu ||
Nit - (!walk->ticket) could just be !walk->ticket.
> + walk->trylock_only)
> + continue;
> +
> + if (!ttm_bo_get_unless_zero(bo)) {
> + ttm_lru_walk_unlock(bo, bo_needs_unlock);
> + continue;
> + }
> +
This kinda goofy pattern too, typically in code a get_unless_zero is
done before trying to lock the object not after. Even odder here, the
could or could not be locked depending on the outcome of
ttm_lru_walk_trylock. This is covering individualization case? Would it
make more sense to move ttm_bo_get_unless_zero before the try lock or is
that to avoid a put on try lock failure + continue?
> + mem_type = res->mem_type;
> + spin_unlock(&bdev->lru_lock);
> +
> + lret = 0;
> + if (!bo_locked && walk->ticket)
As above could you explain the ticket usage a bit more?
Also you shouldn't need to check the ticket here there is !walk->ticket
above which triggers a continue.
> + lret = ttm_lru_walk_ticketlock(walk, bo, &bo_needs_unlock);
> +
> + /*
> + * Note that in between the release of the lru lock and the
> + * ticketlock, the bo may have switched resource,
> + * and also memory type, since the resource may have been
> + * freed and allocated again with a different memory type.
> + * In that case, just skip it.
> + */
> + if (!lret && bo->resource == res && res->mem_type == mem_type)
> + lret = walk->ops->process_bo(walk, bo);
> +
> + ttm_lru_walk_unlock(bo, bo_needs_unlock);
> + ttm_bo_put(bo);
> + if (lret == -EBUSY || lret == -EALREADY)
> + lret = 0;
What is usage of these error codes?
-EALREADY means the resv is locked with the current ticket, right?
Wouldn't we want to call process_bo in this case too?
-EBUSY I need some help figuring out.
> + sofar = (lret < 0) ? lret : sofar + lret;
> + if (sofar < 0 || sofar >= target)
> + goto out;
> +
Here we have dropped the BO unlock. What prevents the BO from being
moved back to the resource we just evicted it from resulting in sofar
not being accurate?
Matt
> + cond_resched();
> + spin_lock(&bdev->lru_lock);
> + }
> + spin_unlock(&bdev->lru_lock);
> +out:
> + ttm_resource_cursor_fini(&cursor);
> + return sofar;
> +}
> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> index 6ccf96c91f3a..8b032298d66e 100644
> --- a/include/drm/ttm/ttm_bo.h
> +++ b/include/drm/ttm/ttm_bo.h
> @@ -190,6 +190,38 @@ struct ttm_operation_ctx {
> uint64_t bytes_moved;
> };
>
> +struct ttm_lru_walk;
> +
> +/** struct ttm_lru_walk_ops - Operations for a LRU walk. */
> +struct ttm_lru_walk_ops {
> + /**
> + * process_bo - Process this bo.
> + * @walk: struct ttm_lru_walk describing the walk.
> + * @bo: A locked and referenced buffer object.
> + *
> + * Return: Negative error code on error, Number of processed pages on
> + * success. 0 also indicates success.
> + */
> + long (*process_bo)(struct ttm_lru_walk *walk, struct ttm_buffer_object *bo);
> +};
> +
> +/**
> + * struct ttm_lru_walk - Structure describing a LRU walk.
> + */
> +struct ttm_lru_walk {
> + /** @ops: Pointer to the ops structure. */
> + const struct ttm_lru_walk_ops *ops;
> + /** @ctx: Pointer to the struct ttm_operation_ctx. */
> + struct ttm_operation_ctx *ctx;
> + /** @ticket: The struct ww_acquire_ctx if any. */
> + struct ww_acquire_ctx *ticket;
> + /** @tryock_only: Only use trylock for locking. */
> + bool trylock_only;
> +};
> +
> +long ttm_lru_walk_for_evict(struct ttm_lru_walk *walk, struct ttm_device *bdev,
> + struct ttm_resource_manager *man, long target);
> +
> /**
> * ttm_bo_get - reference a struct ttm_buffer_object
> *
> --
> 2.44.0
>
next prev parent reply other threads:[~2024-06-18 22:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 7:18 [PATCH v5 00/12] TTM shrinker helpers and xe buffer object shrinker Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 01/12] drm/ttm: Allow TTM LRU list nodes of different types Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 02/12] drm/ttm: Slightly clean up LRU list iteration Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 03/12] drm/ttm: Use LRU hitches Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 04/12] drm/ttm, drm/amdgpu, drm/xe: Consider hitch moves within bulk sublist moves Thomas Hellström
2024-06-19 3:37 ` Matthew Brost
2024-06-19 8:24 ` Thomas Hellström
2024-06-19 14:44 ` Matthew Brost
2024-06-18 7:18 ` [PATCH v5 05/12] drm/ttm: Provide a generic LRU walker helper Thomas Hellström
2024-06-18 22:11 ` Matthew Brost [this message]
2024-06-19 7:31 ` Thomas Hellström
2024-06-19 15:09 ` Matthew Brost
2024-06-18 7:18 ` [PATCH v5 06/12] drm/ttm: Use the LRU walker helper for swapping Thomas Hellström
2024-06-19 4:23 ` Matthew Brost
2024-06-19 8:36 ` Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 07/12] drm/ttm: Use the LRU walker for eviction Thomas Hellström
2024-06-19 22:52 ` Matthew Brost
2024-06-24 9:06 ` Thomas Hellström
2024-06-19 23:33 ` Matthew Brost
2024-06-24 9:16 ` Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 08/12] drm/ttm: Add a virtual base class for graphics memory backup Thomas Hellström
2024-06-20 15:17 ` Matthew Brost
2024-06-24 9:26 ` Thomas Hellström
2024-06-24 15:47 ` Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 09/12] drm/ttm/pool: Provide a helper to shrink pages Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 10/12] drm/ttm: Use fault-injection to test error paths Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 11/12] drm/ttm, drm/xe: Add a shrinker for xe bos Thomas Hellström
2024-06-18 7:18 ` [PATCH v5 12/12] drm/xe: Increase the XE_PL_TT watermark Thomas Hellström
2024-06-18 7:24 ` ✓ CI.Patch_applied: success for TTM shrinker helpers and xe buffer object shrinker (rev5) Patchwork
2024-06-18 7:24 ` ✗ CI.checkpatch: warning " Patchwork
2024-06-18 7:25 ` ✓ CI.KUnit: success " Patchwork
2024-06-18 7:37 ` ✓ CI.Build: " Patchwork
2024-06-18 7:39 ` ✗ CI.Hooks: failure " Patchwork
2024-06-18 7:41 ` ✗ CI.checksparse: warning " Patchwork
2024-06-18 8:03 ` ✓ CI.BAT: success " Patchwork
2024-06-18 19:08 ` ✗ CI.FULL: 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=ZnIGBea3S5fquc32@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=Amaranath.Somalapuram@amd.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@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: 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