mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Davidlohr Bueso <dave@stgolabs.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation
Date: Wed, 10 Apr 2019 11:28:38 -0400	[thread overview]
Message-ID: <402ba759-37ac-dc61-cd61-09e4ae63b65e@redhat.com> (raw)
In-Reply-To: <20190410150714.GK7905@worktop.programming.kicks-ass.net>

On 04/10/2019 11:07 AM, Peter Zijlstra wrote:
> On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote:
>> Because of writer lock stealing, it is possible that a constant
>> stream of incoming writers will cause a waiting writer or reader to
>> wait indefinitely leading to lock starvation.
>>
>> The mutex code has a lock handoff mechanism to prevent lock starvation.
>> This patch implements a similar lock handoff mechanism to disable
>> lock stealing and force lock handoff to the first waiter in the queue
>> after at least a 5ms waiting period. The waiting period is used to
>> avoid discouraging lock stealing too much to affect performance.
> So the mutex code doesn't have that timeout, it foces the handoff if the
> top waiter fails to acquire.
>
> I don't find the above sufficiently justifies the additional complexity.
> What were the numbers with the simple scheme vs this etc..

When the handoff bit is set, it stops the lock from being acquired by
anyone else until the front waiter is woken up, scheduled and take the
lock. Doing that too frequently will impede the throughput when the
rwsem is highly contended. I can ran some performance test to show the
difference it can make.

I have also been thinking about having the front waiter set the handoff
bit and then spin on owner so that it can acquire the lock immediately
after it is freed. It will be a follow up patch.

Cheers,
Longman



  reply	other threads:[~2019-04-10 15:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-05 19:21 [PATCH-tip v2 00/12] locking/rwsem: Rwsem rearchitecture part 2 Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 01/12] locking/rwsem: Implement a new locking scheme Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 02/12] locking/rwsem: Implement lock handoff to prevent lock starvation Waiman Long
2019-04-10 15:07   ` Peter Zijlstra
2019-04-10 15:28     ` Waiman Long [this message]
2019-04-10 15:10   ` Peter Zijlstra
2019-04-10 15:29     ` Waiman Long
2019-04-10 18:44   ` Peter Zijlstra
2019-04-11  2:25     ` Waiman Long
2019-04-11  7:16       ` Peter Zijlstra
2019-04-05 19:21 ` [PATCH-tip v2 03/12] locking/rwsem: Remove rwsem_wake() wakeup optimization Waiman Long
2019-04-10 18:38   ` Davidlohr Bueso
2019-04-05 19:21 ` [PATCH-tip v2 04/12] locking/rwsem: Make rwsem_spin_on_owner() return owner state Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 05/12] locking/rwsem: Ensure an RT task will not spin on reader Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 06/12] locking/rwsem: Wake up almost all readers in wait queue Waiman Long
2019-04-10 16:50   ` Davidlohr Bueso
2019-04-10 17:08     ` Waiman Long
2019-04-10 17:22       ` Davidlohr Bueso
2019-04-10 17:31         ` Davidlohr Bueso
2019-04-10 17:54           ` Waiman Long
2019-04-10 17:53         ` Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 07/12] locking/rwsem: Enable readers spinning on writer Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 08/12] locking/rwsem: Enable time-based spinning on reader-owned rwsem Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 09/12] locking/rwsem: Add more rwsem owner access helpers Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 10/12] locking/rwsem: Guard against making count negative Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 11/12] locking/rwsem: Merge owner into count on x86-64 Waiman Long
2019-04-05 19:21 ` [PATCH-tip v2 12/12] locking/rwsem: Remove redundant computation of writer lock word Waiman Long
2019-04-05 23:27 ` [PATCH-tip v2 00/12] locking/rwsem: Rwsem rearchitecture part 2 Linus Torvalds
2019-04-10 10:00 ` Ingo Molnar
2019-04-10 12:38   ` Waiman Long

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=402ba759-37ac-dc61-cd61-09e4ae63b65e@redhat.com \
    --to=longman@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®