Re: [RFC] Per file OOM badness

On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget

Re: [RFC] Per file OOM badness

On 30.01.2018 12:34, Michel Dänzer wrote: On 2018-01-30 12:28 PM, Christian König wrote: Am 30.01.2018 um 12:02 schrieb Michel Dänzer: On 2018-01-30 11:40 AM, Christian König wrote: Am 30.01.2018 um 10:43 schrieb Michel Dänzer: [SNIP] Would it be ok to hang onto potentially arbitrary mmget

Re: [RFC] Per file OOM badness

On 30.01.2018 11:48, Michel Dänzer wrote: On 2018-01-30 11:42 AM, Daniel Vetter wrote: On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: On 2018-01-30 10:31 AM, Daniel Vetter wrote: I guess a good first order approximation would be if we simply charge any newly allocated buffers

Re: [RFC] Per file OOM badness

On 30.01.2018 11:48, Michel Dänzer wrote: On 2018-01-30 11:42 AM, Daniel Vetter wrote: On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote: On 2018-01-30 10:31 AM, Daniel Vetter wrote: I guess a good first order approximation would be if we simply charge any newly allocated buffers

Re: [git pull] drm for v4.15

On 17.11.2017 20:18, Christian König wrote: The obvious alternative which we are working on for a few years now is to improve the input data we get from the hardware people. In other words instead of getting a flat list of registers we want the information about where and how many times a

Re: [git pull] drm for v4.15

On 17.11.2017 20:18, Christian König wrote: The obvious alternative which we are working on for a few years now is to improve the input data we get from the hardware people. In other words instead of getting a flat list of registers we want the information about where and how many times a

Re: [git pull] drm for v4.15

On 16.11.2017 21:57, Dave Airlie wrote: On 16 November 2017 at 14:59, Linus Torvalds wrote: On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: There is some code touched on sound/soc, but I think the sound tree should have the same commits

Re: [git pull] drm for v4.15

On 16.11.2017 21:57, Dave Airlie wrote: On 16 November 2017 at 14:59, Linus Torvalds wrote: On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: There is some code touched on sound/soc, but I think the sound tree should have the same commits from the same base,so this may luck different if

Re: [PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

On 23.12.2016 11:48, Peter Zijlstra wrote: On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote: diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index a5960e5..b2eaaab 100644 --- a/include/linux/ww_mutex.h +++ b/include/linux/ww_mutex.h @@ -186,11 +186,6 @@ static

Re: [PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

On 23.12.2016 11:48, Peter Zijlstra wrote: On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote: diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h index a5960e5..b2eaaab 100644 --- a/include/linux/ww_mutex.h +++ b/include/linux/ww_mutex.h @@ -186,11 +186,6 @@ static

Re: [PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

On 22.12.2016 02:58, zhoucm1 wrote: On 2016年12月22日 02:46, Nicolai Hähnle wrote: +static inline bool __sched +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b) +{ +return a->stamp - b->stamp <= LONG_MAX && + (a->stamp != b->stamp ||

Re: [PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

On 22.12.2016 02:58, zhoucm1 wrote: On 2016年12月22日 02:46, Nicolai Hähnle wrote: +static inline bool __sched +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b) +{ +return a->stamp - b->stamp <= LONG_MAX && + (a->stamp != b->stamp ||

[PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The function will be re-used in subsequent patches. v3: rename to __ww_ctx_stamp_after (Chris Wilson) Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl>

[PATCH v3 01/12] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan.

[PATCH v3 03/12] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. v3: rename to __ww_ctx_stamp_after (Chris Wilson) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle

[PATCH v3 01/12] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- drivers/gpu/drm/vgem/vgem_fence

[PATCH v3 00/12] locking/ww_mutex: Keep sorted wait list to avoid stampedes

Here's a v3 of the series. Some comments: Patch #1 is already in drm-misc, but I left it here for now for completeness. Patch #2 is new and affects all types of locks, not just the w/w case. It's a race that is exceedingly unlikely: basically, we have to be interrupted right between checking our

[PATCH v3 00/12] locking/ww_mutex: Keep sorted wait list to avoid stampedes

Here's a v3 of the series. Some comments: Patch #1 is already in drm-misc, but I left it here for now for completeness. Patch #2 is new and affects all types of locks, not just the w/w case. It's a race that is exceedingly unlikely: basically, we have to be interrupted right between checking our

[PATCH v3 08/12] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to ba

[PATCH v3 02/12] locking/mutex: Fix a race with handoffs and interruptible waits

From: Nicolai Hähnle <nicolai.haeh...@amd.com> There's a possible race where the waiter in front of us leaves the wait list due to a signal, and the current owner subsequently hands the lock off to us even though we never observed ourselves at the front of the list. Set the task state

[PATCH v3 04/12] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at th

[PATCH v3 04/12] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost of adding

[PATCH v3 02/12] locking/mutex: Fix a race with handoffs and interruptible waits

From: Nicolai Hähnle There's a possible race where the waiter in front of us leaves the wait list due to a signal, and the current owner subsequently hands the lock off to us even though we never observed ourselves at the front of the list. Set the task state before checking our position

[PATCH v3 08/12] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off were either woken up when

[PATCH v3 06/12] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us.

[PATCH v3 06/12] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make sure to call lock_contended

[PATCH v3 11/12] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Ma

[PATCH v3 11/12] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed

[PATCH v3 09/12] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle <nicolai.haeh...@amd.com> In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thr

[PATCH v3 10/12] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we ar

[PATCH v3 09/12] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thread #1 - - successfully

[PATCH v3 10/12] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure that there is no other waiter

[PATCH v3 07/12] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle <nicolai.haeh...@amd.com> While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and

[PATCH v3 07/12] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the first waiter with a c

[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Keep the documentation in the header file since there is no good place for it in mutex.c: there are two rather different implementations with different EXPORT_SYMBOLs for each function. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ing

[PATCH v3 12/12] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffw

[PATCH v3 05/12] locking/ww_mutex: Remove the __ww_mutex_lock inline wrappers

From: Nicolai Hähnle Keep the documentation in the header file since there is no good place for it in mutex.c: there are two rather different implementations with different EXPORT_SYMBOLs for each function. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris

[PATCH v3 12/12] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- Documentation/locking/ww-mutex

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 21:00, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote: mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the wait_lock. mutex_optimistic_spin

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 21:00, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote: mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the wait_lock. mutex_optimistic_spin

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:20, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: @@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, spin_unlock_mutex(>wait_lock, fl

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:20, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: @@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, spin_unlock_mutex(>wait_lock, fl

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:15, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: The concern about picking up a handoff that we didn't request is real, though it cannot happen in the first iteration. Perhaps this __mutex_trylock can be moved to the end of the loop? See

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 16.12.2016 18:15, Peter Zijlstra wrote: On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote: The concern about picking up a handoff that we didn't request is real, though it cannot happen in the first iteration. Perhaps this __mutex_trylock can be moved to the end of the loop? See

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 01.12.2016 16:59, Chris Wilson wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, debug_mutex_lock_common(lock, ); debug_mutex_add_waiter(lock, , task

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 01.12.2016 16:59, Chris Wilson wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, debug_mutex_lock_common(lock, ); debug_mutex_add_waiter(lock, , task

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

Hi Peter and Chris, (trying to combine the handoff discussion here) On 06.12.2016 17:55, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

Hi Peter and Chris, (trying to combine the handoff discussion here) On 06.12.2016 17:55, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 06.12.2016 16:36, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: +static inline int __sched +__ww_mutex_add_waiter(struct mutex_waiter *waiter, + struct mutex *lock, + struct ww_acquire_ctx *ww_ctx

Re: [PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On 06.12.2016 16:36, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: +static inline int __sched +__ww_mutex_add_waiter(struct mutex_waiter *waiter, + struct mutex *lock, + struct ww_acquire_ctx *ww_ctx

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On 06.12.2016 16:25, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, struct mutex_waiter waiter; unsigned long flags; bool first

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

On 06.12.2016 16:25, Peter Zijlstra wrote: On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass, struct mutex_waiter waiter; unsigned long flags; bool first

[PATCH v2 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The function will be re-used in subsequent patches. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffwll.ch>

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan.

[PATCH v2 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- kernel/locking/mutex.c | 10 -- 1 file

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- drivers/gpu/drm/vgem/vgem_fence

[PATCH v2 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-

[PATCH v2 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-appear if the owner task manages

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at th

[PATCH v2 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to ba

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost of adding

[PATCH v2 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off were either woken up when

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us.

[PATCH v2 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffw

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make sure to call lock_contended

[PATCH v2 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- Documentation/locking/ww-mutex

[PATCH v2 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Ma

[PATCH v2 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle <nicolai.haeh...@amd.com> In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thr

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thread #1 - - successfully

[PATCH v2 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we ar

[PATCH v2 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure that there is no other waiter

[PATCH v2 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle <nicolai.haeh...@amd.com> While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and

[PATCH v2 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the first waiter with a c

[PATCH v2 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

Changes to patches 1 & 5 based on feedback. I've also updated the branch at https://cgit.freedesktop.org/~nh/linux/log/?h=mutex. There's been the question of using a balanced tree rather than a list. Frankly, I'd say the 99% use case doesn't need it. Also, dealing with waiters without a context

[PATCH v2 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

Changes to patches 1 & 5 based on feedback. I've also updated the branch at https://cgit.freedesktop.org/~nh/linux/log/?h=mutex. There's been the question of using a balanced tree rather than a list. Frankly, I'd say the 99% use case doesn't need it. Also, dealing with waiters without a context

Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

On 30.11.2016 13:20, Chris Wilson wrote: On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote: On 30.11.2016 10:40, Chris Wilson wrote: On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote: I've included timings taken from a contention-heavy stress test to some

Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

On 30.11.2016 13:20, Chris Wilson wrote: On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote: On 30.11.2016 10:40, Chris Wilson wrote: On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote: I've included timings taken from a contention-heavy stress test to some

Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

On 30.11.2016 10:40, Chris Wilson wrote: On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote: I've included timings taken from a contention-heavy stress test to some of the patches. The stress test performs actual GPU operations which take a good chunk of the wall time, but even so

Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes

On 30.11.2016 10:40, Chris Wilson wrote: On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote: I've included timings taken from a contention-heavy stress test to some of the patches. The stress test performs actual GPU operations which take a good chunk of the wall time, but even so

Re: [PATCH 1/4] locking: Begin kselftests for ww_mutex

On 30.11.2016 01:35, Chris Wilson wrote: Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Nicolai Hähnle <nhaeh...@gmail.com> --- kernel/locking/Makefile|

Re: [PATCH 1/4] locking: Begin kselftests for ww_mutex

On 30.11.2016 01:35, Chris Wilson wrote: Signed-off-by: Chris Wilson Cc: Peter Zijlstra Cc: Maarten Lankhorst Cc: Nicolai Hähnle --- kernel/locking/Makefile| 1 + kernel/locking/test-ww_mutex.c | 137 + lib/Kconfig.debug | 10

[PATCH 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Ma

[PATCH 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle <nicolai.haeh...@amd.com> While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and

[PATCH 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to ba

[PATCH 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed

[PATCH 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the first waiter with a c

[PATCH 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off were either woken up when

[PATCH 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we ar

[PATCH 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure that there is no other waiter

[PATCH 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffw

[PATCH 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-de...@lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- Documentation/locking/ww-mutex

[PATCH 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at th

[PATCH 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost of adding

[PATCH 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us.

[PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffwll.ch> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: dri-de

[PATCH 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-

[PATCH 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle <nicolai.haeh...@amd.com> In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thr

[PATCH 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The function will be re-used in subsequent patches. Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Maarten Lankhorst <d...@mblankhorst.nl> Cc: Daniel Vetter <dan...@ffwll.ch>

[PATCH 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make sure to call lock_contended

  1   2   >