From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, David Vrabel <david.vrabel@citrix.com>
Cc: Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
Christoph Egger <chegger@amazon.de>, Tim Deegan <tim@xen.org>,
Matt Wilson <msw@amazon.com>,
xen-devel@lists.xenproject.org,
Malcolm Crossley <malcolm.crossley@citrix.com>
Subject: Re: [PATCHv7 3/3] gnttab: use per-VCPU maptrack free lists
Date: Tue, 12 May 2015 12:01:13 +0100 [thread overview]
Message-ID: <5551DD79.40507@citrix.com> (raw)
In-Reply-To: <5548D4F60200007800076AA9@mail.emea.novell.com>
On 05/05/15 13:34, Jan Beulich wrote:
>>>> On 30.04.15 at 15:28, <david.vrabel@citrix.com> wrote:
>> From: Malcolm Crossley <malcolm.crossley@citrix.com>
>>
>> Performance analysis of aggregate network throughput with many VMs
>> shows that performance is signficantly limited by contention on the
>> maptrack lock when obtaining/releasing maptrack handles from the free
>> list.
>>
>> Instead of a single free list use a per-VCPU list. This avoids any
>> contention when obtaining a handle. Handles must be released back to
>> their original list and since this may occur on a different VCPU there
>> is some contention on the destination VCPU's free list tail pointer
>> (but this is much better than a per-domain lock).
>>
>> A domain's maptrack limit is multiplied by the number of VCPUs. This
>> ensures that a worst case domain that only performs grant table
>> operations via one VCPU will not see a lower map track limit.
[...]
>> + cur_tail = v->maptrack_tail;
>
> read_atomic()?
It's not required since if this load gets inconsistent state, the
cmpxchg loop will just go around once more. I've added the
read_atomic() anyway, though.
>> @@ -1430,6 +1456,17 @@ gnttab_setup_table(
>> gt = d->grant_table;
>> write_lock(>->lock);
>>
>> + /* Tracking of mapped foreign frames table */
>> + if ( (gt->maptrack = xzalloc_array(struct grant_mapping *,
>> + max_maptrack_frames * d->max_vcpus)) == NULL )
>> + goto out3;
>
> This surely can easily become an allocation of far more than a page,
> and hence needs to be broken up (perhaps using vmap() to map
> individually allocated pages).
I think there should be a common vzalloc_array() function. Do you
agree? This will use xzalloc_array() if the alloc is < PAGE_SIZE to
avoid needlessly using vmap space.
David
next prev parent reply other threads:[~2015-05-12 11:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 13:28 [PATCHv7 0/3] gnttab: Improve scaleability David Vrabel
2015-04-30 13:28 ` [PATCHv7 1/3] gnttab: Introduce rwlock to protect updates to grant table state David Vrabel
2015-05-05 10:42 ` Jan Beulich
2015-04-30 13:28 ` [PATCHv7 2/3] gnttab: refactor locking for scalability David Vrabel
2015-04-30 14:34 ` Tim Deegan
2015-05-01 18:03 ` David Vrabel
2015-05-01 20:02 ` Tim Deegan
2015-05-05 11:58 ` Jan Beulich
2015-04-30 13:28 ` [PATCHv7 3/3] gnttab: use per-VCPU maptrack free lists David Vrabel
2015-04-30 15:12 ` Tim Deegan
2015-05-01 12:29 ` Malcolm Crossley
2015-05-05 12:34 ` Jan Beulich
2015-05-12 11:01 ` David Vrabel [this message]
2015-05-12 11:37 ` Jan Beulich
2015-05-12 12:37 ` David Vrabel
2015-05-12 12:56 ` 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=5551DD79.40507@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=chegger@amazon.de \
--cc=ian.campbell@citrix.com \
--cc=keir@xen.org \
--cc=malcolm.crossley@citrix.com \
--cc=msw@amazon.com \
--cc=tim@xen.org \
--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.