public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org, Rob Clark <robdclark@chromium.org>,
	Akhil P Oommen <quic_akhilpo@quicinc.com>,
	Chia-I Wu <olvaffe@gmail.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Douglas Anderson <dianders@chromium.org>,
	freedreno@lists.freedesktop.org (open list:DRM DRIVER FOR MSM
	ADRENO GPU), Geert Uytterhoeven <geert@linux-m68k.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Gustavo Padovan <gustavo@padovan.org>,
	"Joel Fernandes (Google)" <joel@joelfernandes.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Konrad Dybcio <konrad.dybcio@somainline.org>,
	linaro-mm-sig@lists.linaro.org (moderated list:DMA BUFFER
	SHARING FRAMEWORK), linux-kernel@vger.kernel.org (open list),
	linux-media@vger.kernel.org (open list:DMA BUFFER SHARING
	FRAMEWORK),
	linux-pm@vger.kernel.org (open list:DEVICE FREQUENCY (DEVFREQ)),
	Luca Weiss <luca@z3ntu.xyz>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Sean Paul <sean@poorly.run>
Subject: [PATCH 00/13] drm/msm+PM+icc: Make job_run() reclaim-safe
Date: Sun, 12 Mar 2023 13:41:28 -0700	[thread overview]
Message-ID: <20230312204150.1353517-1-robdclark@gmail.com> (raw)

From: Rob Clark <robdclark@chromium.org>

Inspired by https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vetter@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
and use lockdep annotations to yell at us about anything that could
deadlock against shrinker/reclaim.  Anything that can trigger reclaim,
or block on any other thread that has triggered reclaim, can block the
GPU shrinker from releasing memory if it is waiting the job to complete,
causing deadlock.

The first two patches avoid memory allocation for the hw_fence by
embedding it in the already allocated submit object.  The next three
decouple various allocations that were done in the hw_init path, but
only the first time, to let lockdep see that they won't happen in the
job_run() path.  (The hw_init() path re-initializes the GPU after runpm
resume, etc, which can happen in the job_run() path.)

The remaining patches clean up locking issues in various corners of PM
and interconnect which happen in the runpm path.  These fixes can be
picked up independently by the various maintainers.  In all cases I've
added lockdep annotations to help keep the runpm resume path deadlock-
free vs reclaim, but I've broken those out into their own patches.. it
is possible that these might find issues in other code-paths not hit on
the hw I have.  (It is a bit tricky because of locks held across call-
backs, such as devfreq->lock held across devfreq_dev_profile callbacks.
I've audited these and other callbacks in icc, etc, to look for problems
and fixed one I found in smd-rpm.  But that took me through a number of
drivers and subsystems that I am not familiar with so it is entirely
possible that I overlooked some problematic allocations.)

There is one remaining issue to resolve before we can enable the job_run
annotations, but it is entirely self contained in drm/msm/gem.  So it
should not block review of these patches.  So I figured it best to send
out what I have so far.

Rob Clark (13):
  dma-buf/dma-fence: Add dma_fence_init_noref()
  drm/msm: Embed the hw_fence in msm_gem_submit
  drm/msm/gpu: Move fw loading out of hw_init() path
  drm/msm/gpu: Move BO allocation out of hw_init
  drm/msm/a6xx: Move ioremap out of hw_init path
  PM / devfreq: Drop unneed locking to appease lockdep
  PM / devfreq: Teach lockdep about locking order
  PM / QoS: Fix constraints alloc vs reclaim locking
  PM / QoS: Decouple request alloc from dev_pm_qos_mtx
  PM / QoS: Teach lockdep about dev_pm_qos_mtx locking order
  soc: qcom: smd-rpm: Use GFP_ATOMIC in write path
  interconnect: Fix locking for runpm vs reclaim
  interconnect: Teach lockdep about icc_bw_lock order

 drivers/base/power/qos.c                   | 83 ++++++++++++++++------
 drivers/devfreq/devfreq.c                  | 52 +++++++-------
 drivers/dma-buf/dma-fence.c                | 43 ++++++++---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c      | 48 ++++++-------
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c      | 18 +++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c      | 46 ++++++------
 drivers/gpu/drm/msm/adreno/adreno_device.c |  6 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c    |  9 +--
 drivers/gpu/drm/msm/msm_fence.c            | 43 +++++------
 drivers/gpu/drm/msm/msm_fence.h            |  2 +-
 drivers/gpu/drm/msm/msm_gem.h              | 10 +--
 drivers/gpu/drm/msm/msm_gem_submit.c       |  8 +--
 drivers/gpu/drm/msm/msm_gpu.c              |  4 +-
 drivers/gpu/drm/msm/msm_gpu.h              |  6 ++
 drivers/gpu/drm/msm/msm_ringbuffer.c       |  4 +-
 drivers/interconnect/core.c                | 18 ++++-
 drivers/soc/qcom/smd-rpm.c                 |  2 +-
 include/linux/dma-fence.h                  |  2 +
 18 files changed, 237 insertions(+), 167 deletions(-)

-- 
2.39.2


             reply	other threads:[~2023-03-12 20:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-12 20:41 Rob Clark [this message]
2023-03-12 20:41 ` [PATCH 01/13] dma-buf/dma-fence: Add dma_fence_init_noref() Rob Clark
2023-03-12 20:41 ` [PATCH 02/13] drm/msm: Embed the hw_fence in msm_gem_submit Rob Clark
2023-03-12 20:41 ` [PATCH 03/13] drm/msm/gpu: Move fw loading out of hw_init() path Rob Clark
2023-03-12 20:41 ` [PATCH 04/13] drm/msm/gpu: Move BO allocation out of hw_init Rob Clark
2023-03-12 20:41 ` [PATCH 05/13] drm/msm/a6xx: Move ioremap out of hw_init path Rob Clark
2023-03-12 20:41 ` [PATCH 06/13] PM / devfreq: Drop unneed locking to appease lockdep Rob Clark
2023-03-12 20:41 ` [PATCH 07/13] PM / devfreq: Teach lockdep about locking order Rob Clark
2023-03-12 20:41 ` [PATCH 08/13] PM / QoS: Fix constraints alloc vs reclaim locking Rob Clark
2023-03-13 12:29   ` Rafael J. Wysocki
2023-03-12 20:41 ` [PATCH 09/13] PM / QoS: Decouple request alloc from dev_pm_qos_mtx Rob Clark
2023-03-12 20:41 ` [PATCH 10/13] PM / QoS: Teach lockdep about dev_pm_qos_mtx locking order Rob Clark
2023-03-13 12:31   ` Rafael J. Wysocki
2023-03-13 14:46     ` Rob Clark
2023-03-12 20:41 ` [PATCH 11/13] soc: qcom: smd-rpm: Use GFP_ATOMIC in write path Rob Clark
2023-03-12 20:41 ` [PATCH 12/13] interconnect: Fix locking for runpm vs reclaim Rob Clark
2023-03-12 20:41 ` [PATCH 13/13] interconnect: Teach lockdep about icc_bw_lock order Rob Clark

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=20230312204150.1353517-1-robdclark@gmail.com \
    --to=robdclark@gmail.com \
    --cc=dianders@chromium.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=gustavo@padovan.org \
    --cc=joel@joelfernandes.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=luca@z3ntu.xyz \
    --cc=luzmaximilian@gmail.com \
    --cc=nathan@kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=quic_akhilpo@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=robdclark@chromium.org \
    --cc=sean@poorly.run \
    /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