intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Cc: <jani.nikula@linux.intel.com>, <joonas.lahtinen@linux.intel.com>,
	<simona@ffwll.ch>, <airlied@gmail.com>, <tursulin@ursulin.net>,
	<intel-gfx@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>, <mairacanal@riseup.net>
Subject: Re: [PATCH 9/9 v3] drm/i915: Remove todo and comments about struct_mutex
Date: Fri, 15 Aug 2025 09:03:51 -0400	[thread overview]
Message-ID: <aJ8wNzS_W--oTxGe@intel.com> (raw)
In-Reply-To: <20250813135035.144762-10-luiz.mello@estudante.ufscar.br>

On Wed, Aug 13, 2025 at 10:50:33AM -0300, Luiz Otavio Mello wrote:
> This patch completes the removal of struct_mutex from the driver.
> 
> Remove the related TODO item, as the transition away from struct_mutex
> is now complete.
> 
> Also clean up references to struct_mutex in i915.rst to avoid outdated
> documentation.
> 
> Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  Documentation/gpu/i915.rst |  7 -------
>  Documentation/gpu/todo.rst | 25 -------------------------

drm,drm-misc maintainers, ack to merge this through drm-intel-next?

>  2 files changed, 32 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 72932fa31b8d..eba09c3ddce4 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -358,8 +358,6 @@ Locking Guidelines
>  #. All locking rules and interface contracts with cross-driver interfaces
>     (dma-buf, dma_fence) need to be followed.
>  
> -#. No struct_mutex anywhere in the code
> -
>  #. dma_resv will be the outermost lock (when needed) and ww_acquire_ctx
>     is to be hoisted at highest level and passed down within i915_gem_ctx
>     in the call chain
> @@ -367,11 +365,6 @@ Locking Guidelines
>  #. While holding lru/memory manager (buddy, drm_mm, whatever) locks
>     system memory allocations are not allowed
>  
> -	* Enforce this by priming lockdep (with fs_reclaim). If we
> -	  allocate memory while holding these looks we get a rehash
> -	  of the shrinker vs. struct_mutex saga, and that would be
> -	  real bad.
> -
>  #. Do not nest different lru/memory manager locks within each other.
>     Take them in turn to update memory allocations, relying on the object’s
>     dma_resv ww_mutex to serialize against other operations.
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 92db80793bba..b5f58b4274b1 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -173,31 +173,6 @@ Contact: Simona Vetter
>  
>  Level: Intermediate
>  
> -Get rid of dev->struct_mutex from GEM drivers
> ----------------------------------------------
> -
> -``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
> -everything. Nowadays in modern drivers the only bit where it's mandatory is
> -serializing GEM buffer object destruction. Which unfortunately means drivers
> -have to keep track of that lock and either call ``unreference`` or
> -``unreference_locked`` depending upon context.
> -
> -Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
> -and there's a GEM object ``free`` callback for any drivers which are
> -entirely ``struct_mutex`` free.
> -
> -For drivers that need ``struct_mutex`` it should be replaced with a driver-
> -private lock. The tricky part is the BO free functions, since those can't
> -reliably take that lock any more. Instead state needs to be protected with
> -suitable subordinate locks or some cleanup work pushed to a worker thread. For
> -performance-critical drivers it might also be better to go with a more
> -fine-grained per-buffer object and per-context lockings scheme. Currently only
> -the ``msm`` and `i915` drivers use ``struct_mutex``.
> -
> -Contact: Simona Vetter, respective driver maintainers
> -
> -Level: Advanced
> -
>  Move Buffer Object Locking to dma_resv_lock()
>  ---------------------------------------------
>  
> -- 
> 2.50.1
> 

  reply	other threads:[~2025-08-15 13:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13 13:50 [PATCH 0/9 v3] drm/i915: Remove legacy struct_mutex usage Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 1/9 v3] drm/i915: Move struct_mutex to drm_i915_private Luiz Otavio Mello
2025-08-15 13:04   ` Rodrigo Vivi
2025-08-15 22:15     ` Rodrigo Vivi
2025-08-21 15:21       ` Thomas Zimmermann
2025-08-13 13:50 ` [PATCH 2/9 v3] drm/i915: Remove struct_mutex in i915_irq.c Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 3/9 v3] drm/i915: Change mutex initialization in intel_guc_log Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 4/9 v3] drm/i915: Replace struct_mutex " Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 5/9 v3] drm/i915/gem: Clean-up outdated struct_mutex comments Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 6/9 v3] drm/i915/display: Remove " Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 7/9 v3] drm/i915: Clean-up " Luiz Otavio Mello
2025-08-13 13:50 ` [PATCH 8/9 v3] drm/i915: Drop unused struct_mutex from drm_i915_private Luiz Otavio Mello
2025-08-21 15:55   ` Rodrigo Vivi
2025-08-13 13:50 ` [PATCH 9/9 v3] drm/i915: Remove todo and comments about struct_mutex Luiz Otavio Mello
2025-08-15 13:03   ` Rodrigo Vivi [this message]
2025-08-15 13:22     ` Thomas Zimmermann
2025-08-13 14:18 ` ✗ LGCI.VerificationFailed: failure for drm/i915: Remove legacy struct_mutex usage (rev3) 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=aJ8wNzS_W--oTxGe@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=luiz.mello@estudante.ufscar.br \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mairacanal@riseup.net \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).