lkml.org 
[lkml]   [2018]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 1/2] locking: Implement an algorithm choice for Wound-Wait mutexes
From
Date
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
> On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
>
>> __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
>> {
>> struct mutex_waiter *cur;
>> + unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
>>
>> lockdep_assert_held(&lock->wait_lock);
>>
>> @@ -310,13 +348,14 @@ __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
>> if (!cur->ww_ctx)
>> continue;
>>
>> - if (cur->ww_ctx->acquired > 0 &&
>> + if (is_wait_die && cur->ww_ctx->acquired > 0 &&
>> __ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
>> debug_mutex_wake_waiter(lock, cur);
>> wake_up_process(cur->task);
>> }
>>
>> - break;
>> + if (is_wait_die || __ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
>> + break;
>> }
>> }
> I ended up with:
>
>
> static void __sched
> __ww_mutex_check_waiters(struct mutex *lock, struct ww_acquire_ctx *ww_ctx)
> {
> bool is_wait_die = ww_ctx->ww_class->is_wait_die;
> struct mutex_waiter *cur;
>
> lockdep_assert_held(&lock->wait_lock);
>
> list_for_each_entry(cur, &lock->wait_list, list) {
> if (!cur->ww_ctx)
> continue;
>
> if (is_wait_die) {
> /*
> * Because __ww_mutex_add_waiter() and
> * __ww_mutex_check_stamp() wake any but the earliest
> * context, this can only affect the first waiter (with
> * a context).
> */
> if (cur->ww_ctx->acquired > 0 &&
> __ww_ctx_stamp_after(cur->ww_ctx, ww_ctx)) {
> debug_mutex_wake_waiter(lock, cur);
> wake_up_process(cur->task);
> }
>
> break;
> }
>
> if (__ww_mutex_wound(lock, cur->ww_ctx, ww_ctx))
> break;
> }
> }

Looks OK to me.

>
> Currently you don't allow mixing WD and WW contexts (which is not
> immediately obvious from the above code), and the above hard relies on
> that. Are there sensible use cases for mixing them? IOW will your
> current restriction stand without hassle?

Contexts _must_ agree on the algorithm used to resolve deadlocks. With
Wait-Die, for example, older transactions will wait if a lock is held by
a younger transaction and with Wound-Wait, younger transactions will
wait if a lock is held by an older transaction so there is no way of
mixing them.

Thanks,

/Thomas


\
 
 \ /
  Last update: 2018-06-14 13:55    [W:0.113 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site