Re: [PATCH 4/7] drm/ttm: move LRU walk defines into new internal header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 27.08.24 um 19:53 schrieb Daniel Vetter:
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.

Well I think we have a major disconnect here. When the device is powered down there is no GART mapping to clean up any more.

In other words GART is a table in local memory (VRAM) when the device is powered down this table is completely destroyed. Any BO which was mapped inside this table is now not mapped any more.

So when the shrinker wants to evict a BO which is marked as mapped to GART and the device is powered down we just skip the GART unmapping part because that has already implicitly happened during power down.

Before mapping any BO into the GART again we power the GPU up through the runtime PM calls. And while powering it up again the GART is restored.

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.

What race are you talking about?

The worst thing which could happen is that we restore a GART entry which isn't needed any more, but that is pretty much irrelevant since we only clear them to avoid some hw bugs.

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.

I'm most likely missing something, but I'm really scratching my head where you see a problem here.

Regards,
Christian.

-Sima




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux