Messages in this thread Patch in this message | | | From | Nicolai Hähnle <> | Subject | [PATCH 10/11] Documentation/locking/ww_mutex: Update the design document | Date | Mon, 28 Nov 2016 13:20:11 +0100 |
| |
From: Nicolai Hähnle <Nicolai.Haehnle@amd.com>
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Maarten Lankhorst <dev@mblankhorst.nl> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Nicolai Hähnle <Nicolai.Haehnle@amd.com> --- Documentation/locking/ww-mutex-design.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/locking/ww-mutex-design.txt b/Documentation/locking/ww-mutex-design.txt index 8a112dc..34c3a1b 100644 --- a/Documentation/locking/ww-mutex-design.txt +++ b/Documentation/locking/ww-mutex-design.txt @@ -309,11 +309,15 @@ Design: normal mutex locks, which are far more common. As such there is only a small increase in code size if wait/wound mutexes are not used. + We maintain the following invariants for the wait list: + (1) Waiters with an acquire context are sorted by stamp order; waiters + without an acquire context are interspersed in FIFO order. + (2) Among waiters with contexts, only the first one can have other locks + acquired already (ctx->acquired > 0). Note that this waiter may come + after other waiters without contexts in the list. + In general, not much contention is expected. The locks are typically used to - serialize access to resources for devices. The only way to make wakeups - smarter would be at the cost of adding a field to struct mutex_waiter. This - would add overhead to all cases where normal mutexes are used, and - ww_mutexes are generally less performance sensitive. + serialize access to resources for devices. Lockdep: Special care has been taken to warn for as many cases of api abuse -- 2.7.4
| |