All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.
Date: Mon, 17 Jan 2022 15:08:23 +0100	[thread overview]
Message-ID: <fb8f8150-bdc3-32aa-5352-5f15ae91a592@linux.intel.com> (raw)
In-Reply-To: <20220117075604.131477-1-maarten.lankhorst@linux.intel.com>


On 1/17/22 08:56, Maarten Lankhorst wrote:
> i915_gem_evict_vm will need to be able to evict objects that are
> locked by the current ctx. By testing if the current context already
> locked the object, we can do this correctly. This allows us to
> evict the entire vm even if we already hold some objects' locks.
>
> Previously, this was spread over several commits, but it makes
> more sense to commit the changes to i915_gem_evict_vm separately
> from the changes to i915_gem_evict_something() and
> i915_gem_evict_for_node().
>
> Changes since v1:
> - Handle evicting dead objects better.
> Changes since v2:
> - Use for_i915_gem_ww in igt_evict_vm. (Thomas)
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>

(Please note the series checkpatch- and DOC warnings before commiting!)

Thanks,

Thomas



WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.
Date: Mon, 17 Jan 2022 15:08:23 +0100	[thread overview]
Message-ID: <fb8f8150-bdc3-32aa-5352-5f15ae91a592@linux.intel.com> (raw)
In-Reply-To: <20220117075604.131477-1-maarten.lankhorst@linux.intel.com>


On 1/17/22 08:56, Maarten Lankhorst wrote:
> i915_gem_evict_vm will need to be able to evict objects that are
> locked by the current ctx. By testing if the current context already
> locked the object, we can do this correctly. This allows us to
> evict the entire vm even if we already hold some objects' locks.
>
> Previously, this was spread over several commits, but it makes
> more sense to commit the changes to i915_gem_evict_vm separately
> from the changes to i915_gem_evict_something() and
> i915_gem_evict_for_node().
>
> Changes since v1:
> - Handle evicting dead objects better.
> Changes since v2:
> - Use for_i915_gem_ww in igt_evict_vm. (Thomas)
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>

(Please note the series checkpatch- and DOC warnings before commiting!)

Thanks,

Thomas



  reply	other threads:[~2022-01-17 14:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-14 13:23 [PATCH v6 0/6] drm/i915: Remove short term pins from execbuf by requiring lock to unbind Maarten Lankhorst
2022-01-14 13:23 ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 13:23 ` [PATCH v6 1/6] drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC errors, v2 Maarten Lankhorst
2022-01-14 13:23   ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 13:23 ` [PATCH v6 2/6] drm/i915: Add locking to i915_gem_evict_vm(), v2 Maarten Lankhorst
2022-01-14 13:23   ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 13:57   ` Thomas Hellström (Intel)
2022-01-17  7:56     ` [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3 Maarten Lankhorst
2022-01-17  7:56       ` [Intel-gfx] " Maarten Lankhorst
2022-01-17 14:08       ` Thomas Hellström [this message]
2022-01-17 14:08         ` Thomas Hellström
2022-01-18 14:50         ` Maarten Lankhorst
2022-01-18 14:50           ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 13:23 ` [Intel-gfx] [PATCH v6 3/6] drm/i915: Add object locking to i915_gem_evict_for_node and i915_gem_evict_something, v2 Maarten Lankhorst
2022-01-14 13:23   ` Maarten Lankhorst
2022-01-14 13:23 ` [Intel-gfx] [PATCH v6 4/6] drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for i915_vma_unbind, v2 Maarten Lankhorst
2022-01-14 13:23   ` Maarten Lankhorst
2022-01-14 13:23 ` [PATCH v6 5/6] drm/i915: Remove support for unlocked i915_vma unbind Maarten Lankhorst
2022-01-14 13:23   ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 13:23 ` [PATCH v6 6/6] drm/i915: Remove short-term pins from execbuf, v6 Maarten Lankhorst
2022-01-14 13:23   ` [Intel-gfx] " Maarten Lankhorst
2022-01-14 15:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove short term pins from execbuf by requiring lock to unbind Patchwork
2022-01-14 15:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-14 15:10 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2022-01-14 15:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-17  8:08 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Remove short term pins from execbuf by requiring lock to unbind. (rev2) Patchwork
2022-01-17  8:09 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-17  8:13 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2022-01-17  8:43 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-17 10:43 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove short term pins from execbuf by requiring lock to unbind Patchwork
2022-01-17 14:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove short term pins from execbuf by requiring lock to unbind. (rev2) 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=fb8f8150-bdc3-32aa-5352-5f15ae91a592@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 \
    /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 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.