All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <waiman.long@hp.com>
To: walken@google.com
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-arch@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>, Rik van Riel <riel@redhat.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	George Spelvin <linux@horizon.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	"Chandramouleeswaran, Aswin" <aswin@hp.com>,
	"Norton, Scott J" <scott.norton@hp.com>
Subject: Re: [PATCH v4 1/3] qrwlock: A queue read/write lock implementation
Date: Wed, 23 Oct 2013 12:58:10 -0400	[thread overview]
Message-ID: <52680022.1020200@hp.com> (raw)
In-Reply-To: <20131023120004.GD2862@localhost>

On 10/23/2013 08:00 AM, walken@google.com wrote:
> On Wed, Oct 02, 2013 at 10:09:04AM -0400, Waiman Long wrote:
>>
>> Tim Chen also tested the qrwlock with Ingo's patch on a 4-socket
>> machine.  It was found the performance improvement of 11% was the
>> same with regular rwlock or queue rwlock.
>>
>> Signed-off-by: Waiman Long<Waiman.Long@hp.com>
> I haven't followed all the locking threads lately; did this get into any
> tree yet and is it still being considered ?

I think it is still being considered. I am hoping that it can get into 
3.13, if possible.

>> + * Writer state values&  mask
>> + */
>> +#define	QW_WAITING	1			/* A writer is waiting	   */
>> +#define	QW_LOCKED	0xff			/* A writer holds the lock */
>> +#define QW_MASK_FAIR	((u8)~QW_WAITING)	/* Mask for fair reader    */
>> +#define QW_MASK_UNFAIR	((u8)~0)		/* Mask for unfair reader  */
> I'm confused - I expect fair readers want to queue behind a waiting writer,
> so shouldn't this be QW_MASK_FAIR=~0 and QW_MASK_UNFAIR=~QW_WAITING ?

Yes, you are right. I think I had mixed up the values in a revision to 
the patch. I will send out an updated patch with the right values.

>> +/**
>> + * wait_in_queue - Add to queue and wait until it is at the head
>> + * @lock: Pointer to queue rwlock structure
>> + * @node: Node pointer to be added to the queue
>> + *
>> + * The use of smp_wmb() is to make sure that the other CPUs see the change
>> + * ASAP.
>> + */
>> +static __always_inline void
>> +wait_in_queue(struct qrwlock *lock, struct qrwnode *node)
>> +{
>> +	struct qrwnode *prev;
>> +
>> +	node->next = NULL;
>> +	node->wait = true;
>> +	prev = xchg(&lock->waitq, node);
>> +	if (prev) {
>> +		prev->next = node;
>> +		smp_wmb();
>> +		/*
>> +		 * Wait until the waiting flag is off
>> +		 */
>> +		while (ACCESS_ONCE(node->wait))
>> +			cpu_relax();
>> +	}
>> +}
>> +
>> +/**
>> + * signal_next - Signal the next one in queue to be at the head
>> + * @lock: Pointer to queue rwlock structure
>> + * @node: Node pointer to the current head of queue
>> + */
>> +static __always_inline void
>> +signal_next(struct qrwlock *lock, struct qrwnode *node)
>> +{
>> +	struct qrwnode *next;
>> +
>> +	/*
>> +	 * Try to notify the next node first without disturbing the cacheline
>> +	 * of the lock. If that fails, check to see if it is the last node
>> +	 * and so should clear the wait queue.
>> +	 */
>> +	next = ACCESS_ONCE(node->next);
>> +	if (likely(next))
>> +		goto notify_next;
>> +
>> +	/*
>> +	 * Clear the wait queue if it is the last node
>> +	 */
>> +	if ((ACCESS_ONCE(lock->waitq) == node)&&
>> +	    (cmpxchg(&lock->waitq, node, NULL) == node))
>> +			return;
>> +	/*
>> +	 * Wait until the next one in queue set up the next field
>> +	 */
>> +	while (likely(!(next = ACCESS_ONCE(node->next))))
>> +		cpu_relax();
>> +	/*
>> +	 * The next one in queue is now at the head
>> +	 */
>> +notify_next:
>> +	barrier();
>> +	ACCESS_ONCE(next->wait) = false;
>> +	smp_wmb();
>> +}
> I believe this could be unified with mspin_lock() / mspin_unlock() in
> kernel/mutex.c ? (there is already talk of extending these functions
> to be used by rwsem for adaptive spinning as well...)

It probably can, but the unification can wait until the code are in.

> Not a full review yet - I like the idea of making rwlock more fair but
> I haven't dug too much into the details yet.
>

Thank for taking the time to review it.

-Longman

  reply	other threads:[~2013-10-23 16:58 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-02 14:09 [PATCH v4 0/3] qrwlock: Introducing a queue read/write lock implementation Waiman Long
2013-10-02 14:09 ` Waiman Long
2013-10-02 14:09 ` [PATCH v4 1/3] qrwlock: A " Waiman Long
2013-10-02 14:09   ` Waiman Long
2013-10-23 12:00   ` walken
2013-10-23 16:58     ` Waiman Long [this message]
2013-10-24 10:14       ` Thomas Gleixner
2013-10-24 14:12         ` Waiman Long
2013-10-24 16:24           ` Tim Chen
2013-10-02 14:09 ` Waiman Long
2013-10-02 14:09 ` [PATCH v4 2/3] qrwlock x86: Enable x86 to use queue read/write lock Waiman Long
2013-10-02 14:09 ` Waiman Long
2013-10-02 14:09   ` Waiman Long
2013-10-02 14:09 ` [PATCH v4 3/3] qrwlock: Enable fair " Waiman Long
2013-10-02 14:09   ` Waiman Long
2013-10-02 14:09 ` Waiman Long
2013-10-02 15:19 ` [PATCH v4 0/3] qrwlock: Introducing a queue read/write lock implementation Peter Zijlstra
2013-10-02 15:25   ` Ingo Molnar

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=52680022.1020200@hp.com \
    --to=waiman.long@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arnd@arndb.de \
    --cc=aswin@hp.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=riel@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=scott.norton@hp.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=walken@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.