From: Thomas Hellstrom <thellstrom@vmware.com>
To: airlied@redhat.com, airlied@gmail.com
Cc: pv-drivers@vmware.com, Thomas Hellstrom <thellstrom@vmware.com>,
linux-graphics-maintainer@vmware.com,
dri-devel@lists.freedesktop.org
Subject: [git pull] vmwgfx-next WW mutex update
Date: Tue, 3 Jul 2018 12:53:39 +0200 [thread overview]
Message-ID: <20180703105339.4461-1-thellstrom@vmware.com> (raw)
Hi, Dave.
A patchset worked out together with Peter Zijlstra. Ingo is OK with taking
it through the DRM tree:
This is a small fallout from a work to allow batching WW mutex locks and
unlocks.
Our Wound-Wait mutexes actually don't use the Wound-Wait algorithm but
the Wait-Die algorithm. One could perhaps rename those mutexes tree-wide to
"Wait-Die mutexes" or "Deadlock Avoidance mutexes". Another approach suggested
here is to implement also the "Wound-Wait" algorithm as a per-WW-class
choice, as it has advantages in some cases. See for example
http://www.mathcs.emory.edu/~cheung/Courses/554/Syllabus/8-recv+serial/deadlock-compare.html
Now Wound-Wait is a preemptive algorithm, and the preemption is implemented
using a lazy scheme: If a wounded transaction is about to go to sleep on
a contended WW mutex, we return -EDEADLK. That is sufficient for deadlock
prevention. Since with WW mutexes we also require the aborted transaction to
sleep waiting to lock the WW mutex it was aborted on, this choice also provides
a suitable WW mutex to sleep on. If we were to return -EDEADLK on the first
WW mutex lock after the transaction was wounded whether the WW mutex was
contended or not, the transaction might frequently be restarted without a wait,
which is far from optimal. Note also that with the lazy preemption scheme,
contrary to Wait-Die there will be no rollbacks on lock contention of locks
held by a transaction that has completed its locking sequence.
The modeset locks are then changed from Wait-Die to Wound-Wait since the
typical locking pattern of those locks very well matches the criterion for
a substantial reduction in the number of rollbacks. For reservation objects,
the benefit is more unclear at this point and they remain using Wait-Die.
The following changes since commit eab976693153b9854bfa83d131374748f6ca4280:
Merge tag 'drm-misc-next-2018-06-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-06-28 13:29:07 +1000)
are available in the Git repository at:
git://people.freedesktop.org/~thomash/linux vmwgfx-next
for you to fetch changes up to 07c13bb78c8b8a9cb6ee169659528945038d5e85:
drm: Change deadlock-avoidance algorithm for the modeset locks. (2018-07-03 09:46:05 +0200)
----------------------------------------------------------------
Peter Ziljstra (1):
locking: WW mutex cleanup
Thomas Hellstrom (2):
locking: Implement an algorithm choice for Wound-Wait mutexes
drm: Change deadlock-avoidance algorithm for the modeset locks.
Documentation/locking/ww-mutex-design.txt | 65 ++++--
drivers/dma-buf/reservation.c | 2 +-
include/linux/ww_mutex.h | 45 ++--
kernel/locking/locktorture.c | 2 +-
kernel/locking/mutex.c | 345 +++++++++++++++++++++++-------
kernel/locking/test-ww_mutex.c | 2 +-
lib/locking-selftest.c | 2 +-
7 files changed, 344 insertions(+), 119 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
reply other threads:[~2018-07-03 10:54 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20180703105339.4461-1-thellstrom@vmware.com \
--to=thellstrom@vmware.com \
--cc=airlied@gmail.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=pv-drivers@vmware.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;
as well as URLs for NNTP newsgroup(s).