From: Malcolm Crossley <malcolm.crossley@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com,
keir@xen.org, ian.campbell@citrix.com,
Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock
Date: Thu, 19 Nov 2015 09:03:25 +0000 [thread overview]
Message-ID: <564D905D.4080005@citrix.com> (raw)
In-Reply-To: <20151118200211.GE1762@char.us.oracle.com>
On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:30:59PM +0000, Andrew Cooper wrote:
>> On 17/11/15 17:04, Jan Beulich wrote:
>>>>>> On 03.11.15 at 18:58, <malcolm.crossley@citrix.com> wrote:
>>>> --- a/xen/common/grant_table.c
>>>> +++ b/xen/common/grant_table.c
>>>> @@ -178,6 +178,10 @@ struct active_grant_entry {
>>>> #define _active_entry(t, e) \
>>>> ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
>>>>
>>>> +bool_t grant_rwlock_barrier;
>>>> +
>>>> +DEFINE_PER_CPU(rwlock_t *, grant_rwlock);
>>> Shouldn't these be per grant table? And wouldn't doing so eliminate
>>> the main limitation of the per-CPU rwlocks?
>>
>> The grant rwlock is per grant table.
>>
>> The entire point of this series is to reduce the cmpxchg storm which
>> happens when many pcpus attempt to grap the same domains grant read lock.
>>
>> As identified in the commit message, reducing the cmpxchg pressure on
>> the cache coherency fabric increases intra-vm network through from
>> 10Gbps to 50Gbps when running iperf between two 16-vcpu guests.
>>
>> Or in other words, 80% of cpu time is wasted with waiting on an atomic
>> read/modify/write operation against a remote hot cache line.
>>
>
> Why not use MCE locks then (in Linux the implemention is known
> as qspinlock). Plus they have added extra code to protect against
> recursion (via four levels). See Linux commit
> a33fda35e3a7655fb7df756ed67822afb5ed5e8d
> locking/qspinlock: Introduce a simple generic 4-byte queued spinlock)
>
The Linux qspinlock is MCS based but MCS only helps under lock contention.
It still uses a single data location for the lock and so suffers from
cache line bouncing plus the cmpxchg overhead for taking a uncontended lock.
You can see the qspinlock using the cmpxchg mechanism here:
http://lxr.free-electrons.com/source/include/asm-generic/qspinlock.h#L62
I've copy pasted the qspinlock lock implementation inline for convenience:
static __always_inline void queued_spin_lock(struct qspinlock *lock)
{
u32 val;
val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
if (likely(val == 0))
return;
queued_spin_lock_slowpath(lock, val);
}
Malcolm
>> ~Andrew
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-11-19 9:03 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-03 17:58 [PATCH 1/2] rwlock: add per-cpu reader-writer locks Malcolm Crossley
2015-11-03 17:58 ` [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock Malcolm Crossley
2015-11-17 17:04 ` Jan Beulich
2015-11-17 17:30 ` Andrew Cooper
2015-11-17 17:39 ` Jan Beulich
2015-11-17 17:53 ` Andrew Cooper
2015-11-18 7:45 ` Jan Beulich
2015-11-18 10:06 ` Andrew Cooper
2015-11-18 10:48 ` Jan Beulich
2015-11-18 10:36 ` Ian Campbell
2015-11-18 10:54 ` Jan Beulich
2015-11-18 11:23 ` Malcolm Crossley
2015-11-18 11:41 ` Jan Beulich
2015-11-18 11:50 ` Malcolm Crossley
2015-11-18 11:50 ` Ian Campbell
2015-11-18 11:56 ` Malcolm Crossley
2015-11-18 12:07 ` Ian Campbell
2015-11-18 13:08 ` Malcolm Crossley
2015-11-18 13:47 ` Jan Beulich
2015-11-18 14:22 ` Ian Campbell
2015-11-18 20:02 ` Konrad Rzeszutek Wilk
2015-11-19 9:03 ` Malcolm Crossley [this message]
2015-11-19 10:09 ` Andrew Cooper
2015-11-05 13:48 ` [PATCH 1/2] rwlock: add per-cpu reader-writer locks Marcos E. Matsunaga
2015-11-05 15:20 ` Malcolm Crossley
2015-11-05 15:46 ` Marcos E. Matsunaga
2015-11-17 17:00 ` Jan Beulich
2015-11-18 13:49 ` Malcolm Crossley
2015-11-18 14:15 ` Jan Beulich
2015-11-18 16:21 ` Malcolm Crossley
2015-11-18 17:04 ` Jan Beulich
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=564D905D.4080005@citrix.com \
--to=malcolm.crossley@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xenproject.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.