From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/7] drm/ttm: move LRU walk defines into new internal header
Date: Tue, 27 Aug 2024 19:53:55 +0200 [thread overview]
Message-ID: <Zs4Ss8LJ-n9NbBcb@phenom.ffwll.local> (raw)
In-Reply-To: <Zs4EPT1DR7OrE5X-@phenom.ffwll.local>
On Tue, Aug 27, 2024 at 06:52:13PM +0200, Daniel Vetter wrote:
> On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote:
> > Completely agree that this is complicated, but I still don't see the need
> > for it.
> >
> > Drivers just need to use pm_runtime_get_if_in_use() inside the shrinker and
> > postpone all hw activity until resume.
>
> Not good enough, at least long term I think. Also postponing hw activity
> to resume doesn't solve the deadlock issue, if you still need to grab ttm
> locks on resume.
Pondered this specific aspect some more, and I think you still have a race
here (even if you avoid the deadlock): If the condiditional rpm_get call
fails there's no guarantee that the device will suspend/resume and clean
up the GART mapping. The race gets a bit smaller if you use
pm_runtime_get_if_active(), but even then you might catch it right when
resume almost finished.
That means we'll have ttm bo hanging around with GART allocations/mappings
which aren't actually valid anymore (since they might escape the cleanup
upon resume due to the race). That doesn't feel like a solid design
either.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2024-08-27 17:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 12:42 Using drm_exec in TTM Christian König
2024-07-10 12:42 ` [PATCH 1/7] dma-buf/dma-resv: Introduce dma_resv_trylock_ctx() Christian König
2024-07-10 12:42 ` [PATCH 2/7] drm/exec: don't immediately add the prelocked obj Christian König
2024-07-10 12:42 ` [PATCH 3/7] drm/exec: provide trylock interface for eviction Christian König
2024-07-10 12:42 ` [PATCH 4/7] drm/ttm: move LRU walk defines into new internal header Christian König
2024-07-10 18:19 ` Matthew Brost
2024-07-11 12:01 ` Christian König
2024-07-11 16:00 ` Matthew Brost
2024-08-06 8:29 ` Thomas Hellström
2024-08-19 11:03 ` Christian König
2024-08-19 11:38 ` Thomas Hellström
2024-08-19 14:14 ` Daniel Vetter
2024-08-19 15:26 ` Christian König
2024-08-20 10:37 ` Thomas Hellström
2024-08-20 15:45 ` Christian König
2024-08-20 16:00 ` Thomas Hellström
2024-08-21 8:14 ` Christian König
2024-08-21 8:57 ` Thomas Hellström
2024-08-21 9:31 ` Thomas Hellström
2024-08-21 9:48 ` Christian König
2024-08-21 12:00 ` Thomas Hellström
2024-08-22 6:47 ` Thomas Hellström
2024-08-22 7:55 ` Christian König
2024-08-22 8:21 ` Thomas Hellström
2024-08-22 8:36 ` Thomas Hellström
2024-08-22 9:29 ` Christian König
2024-08-22 13:16 ` Thomas Hellström
2024-08-27 16:58 ` Daniel Vetter
2024-08-22 9:23 ` Daniel Vetter
2024-08-22 13:19 ` Christian König
2024-08-27 16:52 ` Daniel Vetter
2024-08-27 17:53 ` Daniel Vetter [this message]
2024-08-28 12:20 ` Christian König
2024-08-28 14:05 ` Thomas Hellström
2024-08-28 15:25 ` Christian König
2024-08-28 15:35 ` Alex Deucher
2024-08-28 15:45 ` Thomas Hellström
2024-09-02 11:07 ` Daniel Vetter
2024-09-18 12:57 ` Thomas Hellström
2024-10-02 11:30 ` Thomas Hellström
2024-10-02 11:32 ` Christian König
2024-10-02 11:36 ` Thomas Hellström
2024-10-07 9:08 ` Christian König
2024-10-09 13:39 ` Thomas Hellström
2024-10-09 14:17 ` Thomas Hellström
2024-10-10 8:00 ` Christian König
2024-10-11 16:52 ` Thomas Hellström
2024-08-27 18:24 ` Alex Deucher
2024-09-02 11:00 ` Daniel Vetter
2024-08-21 7:02 ` Thomas Hellström
2024-07-10 12:42 ` [PATCH 5/7] drm/ttm: move needs_unlock into the walk Christian König
2024-07-10 12:43 ` [PATCH 6/7] drm/ttm: support using drm_exec during eviction v2 Christian König
2024-07-10 12:43 ` [PATCH 7/7] drm/amdgpu: use drm_exec during BO validation Christian König
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=Zs4Ss8LJ-n9NbBcb@phenom.ffwll.local \
--to=daniel.vetter@ffwll.ch \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--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