[Bug 111882] [CI][SHARDS] GLK: igt at gem_eio@kms - dmesg-warn - WARNING: possible circular locking dependency detected
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Oct 4 16:10:41 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=111882
Chris Wilson <chris at chris-wilson.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit b1e3177bd1d8f41e2a9cc847e56a96cdc0eefe62
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date: Fri Oct 4 14:40:00 2019 +0100
drm/i915: Coordinate i915_active with its own mutex
Forgo the struct_mutex serialisation for i915_active, and interpose its
own mutex handling for active/retire.
This is a multi-layered sleight-of-hand. First, we had to ensure that no
active/retire callbacks accidentally inverted the mutex ordering rules,
nor assumed that they were themselves serialised by struct_mutex. More
challenging though, is the rule over updating elements of the active
rbtree. Instead of the whole i915_active now being serialised by
struct_mutex, allocations/rotations of the tree are serialised by the
i915_active.mutex and individual nodes are serialised by the caller
using the i915_timeline.mutex (we need to use nested spinlocks to
interact with the dma_fence callback lists).
The pain point here is that instead of a single mutex around execbuf, we
now have to take a mutex for active tracker (one for each vma, context,
etc) and a couple of spinlocks for each fence update. The improvement in
fine grained locking allowing for multiple concurrent clients
(eventually!) should be worth it in typical loads.
v2: Add some comments that barely elucidate anything :(
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
Link:
https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-6-chris@chris-wilson.co.uk
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20191004/a573b07d/attachment.html>
More information about the intel-gfx-bugs
mailing list