gnttab: Improve scaleability
v9 cover gnttab: Improve scaleability
The series builds on the original series by Matt Wilson and Christoph Egger from Amazon.
Performance results for aggregate intrahost network throughput (between 20 VM pairs, with 16 dom0 VCPUs) show substantial improvements.
Throughput/Gbit/s
Base 9.7
Split locks 25.8
Split locks 42.9
+ per-VCPU maptrack lists
v9:
* Refactor the locking patches into three commits:
1. Add per-active entry locking.
2. Add maptrack_lock.
3. Make the grant table lock a read-write lock.
* Keep the double lock around IOMMU updates, but adjust their scope to only the IOMMU updates.
v8:
* Misc locking fixes.
* Use read/write_atomic() in per-VCPU maptrack free list.
* Improve locking docs.
v7:
* Re-add grant table rwlock (locking was broken without it and the gains are minimal anyway).
* Remove unneeded locks from grant_table_destroy().
* Fix get_maptrack_handle() locking.
v6:
* Remove most uses of the grant table lock.
* Make the grant table lock a spin lock again (there were only writers left after the above)
* Add per-VCPU maptrack free lists.
v5:
* Addressed locking issue pointed out by Jan Beulich
* Fixed git rebase merge issue introduced in v4 (acquiring locking twice)
* Change for ()-loop in grant_map_exists
* Coding style fixes
v4:
* Coding style nits from Jan Beulich
* Fixup read locks pointed out by Jan Beulich
* renamed double_gt_(un)lock to double_maptrack_(un)lock per request from Jan Beulich
* Addressed ASSERT()'s from Jan Beulich
* Addressed locking issues in unmap_common pointed out by Jan Beulich
v3:
* Addressed gnttab_swap_grant_ref() comment from Andrew Cooper
v2:
* Add arm part per request from Julien Grall
David
PATCH v9 1/4 gnttab: per-active entry locking
Introduce a per-active entry spin lock to protect active entry state The grant table lock must be locked before acquiring (locking) an active entry.
This is a step in reducing contention on the grant table lock, but will only do so once the grant table lock is turned into a read-write lock.
Based on a patch originally by Matt Wilson <[email protected]>.
--- docs/misc/grant-tables.txt | 42 ++++++++++++- xen/common/grant_table.c | 146 ++++++++++++++++++++++++++++++++------------ 2 files changed, 147 insertions(+), 41 deletions(-)
docs/misc/grant-tables.txt +41 -1
@@ -63,6 +63,7 @@ is complete. act->domid : remote domain being granted rights act->frame : machine frame being granted act->pin : used to hold reference counts + act->lock : spinlock used to serialize access to active entry state Map tracking ~~~~~~~~~~~~
@@ -74,7 +75,46 @@ is complete. matching map track entry is then removed, as if unmap had been invoked. These are not used by the transfer mechanism. map->domid : owner of the mapped frame - map->ref_and_flags : grant reference, ro/rw, mapped for host or device access + map->ref : grant reference + map->flags : ro/rw, mapped for host or device access + +******************************************************************************** + Locking + ~~~~~~~ + Xen uses several locks to serialize access to the internal grant table state. + + grant_table->lock : lock used to prevent readers from accessing + inconsistent grant table state such as current + version, partially initialized active table pages, + etc. + active_grant_entry->lock : spinlock used to serialize modifications to + active entries + + The primary lock for the grant table is a spinlock. All functions + that access members of struct grant_table must acquire the lock + around critical sections. + + Active entries are obtained by calling active_entry_acquire(gt, ref). + This function returns a pointer to the active entry after locking its + spinlock. The caller must hold the grant table lock for the gt in + question before calling active_entry_acquire(). This is because the + grant table can be dynamically extended via gnttab_grow_table() while + a domain is running and must be fully initialized. Once all access to + the active entry is complete, release the lock by calling + active_entry_release(act). + + Summary of rules for locking: + active_entry_acquire() and active_entry_release() can only be + called when holding the relevant grant table's lock. I.e.: + spin_lock(>->lock); + act = active_entry_acquire(gt, ref); + ... + active_entry_release(act); + spin_unlock(>->lock); + + Active entries cannot be acquired while holding the maptrack lock. + Multiple active entries can be acquired while holding the grant table + lock. ********************************************************************************
xen/common/grant_table.c +106 -40
421 lines not on this page · raw message
Signature · 1 line
1.7.10.4
Re: [PATCHv9 1/4] gnttab: per-active entry locking
Quoted 11 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +1
-1@@ -505,7 +526,7 @@ static int grant_map_exists(const struct domain *ld,unsigned long mfn, unsigned int *ref_count) { - const struct active_grant_entry *act; + struct active_grant_entry *act;unsigned int ref, max_iter;ASSERT (spin_is_locked (&rgt->lock));
xen/common/grant_table.c static int grant_map_exists(const struct domain *ld, · line 538
Quoted 5 lines
xen/common/grant_table.c +1
-1@@ -514,18 +535,18 @@ static int grant_map_exists(const struct domain *ld, nr_grant_entries(rgt));for ( ref = *ref_count; ref < max_iter; ref++ ) { - act = &active_entry (rgt, ref); +bool_t exists;
With this I think act's declaration should move into this more narrow scope too, the more that you need to drop its const anyway.
xen/common/grant_table.c __gnttab_map_grant_ref( · line 733
Quoted 6 lines
xen/common/grant_table.c +1
-0@@ -702,6 +729,7 @@ __gnttab_map_grant_ref( cache_flags = (shah->flags & (GTF_PAT |GTF_PWT |GTF_PCD ) ); +active_entry_release (act);spin_unlock (&rgt->lock);
Just for my understanding: The lock isn't meant to also cover *shah? I.e. it could be dropped ahead of the cache_flags assignment?
xen/common/grant_table.c __gnttab_unmap_common( · line 1015
Quoted 9 lines
xen/common/grant_table.c +1
-1@@ -978,7 +1009,7 @@ __gnttab_unmap_common(if ( (rc =replace_grant_host_mapping (op->host_addr, op->frame, op->new_addr, op->flags)) <0 ) - goto unmap_out; + goto act_release_out;ASSERT (act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask)); op->map->flags &= ~GNTMAP_host_map;
act doesn't look to be accessed anymore after the if() this is contained in - why don't you drop the lock as early as possible? Or wait - do we need act->pin to remain stable until after that subsequent if() (in which case dropping the lock before the final if() in the function would mainly make error handling more cumbersome without bying us much)?
Quoted 13 lines
xen/common/grant_table.c +3
-0@@ -1979,8 +2026,11 @@ __acquire_grant_for_copy( &trans_page_off, &trans_length, 0);spin_lock (&rgt->lock); + act =active_entry_acquire (rgt, gref); +if ( rc != GNTST_okay ) {__fixup_status_for_copy_pin (act, status); +active_entry_release (act);rcu_unlock_domain (td);spin_unlock (&rgt->lock);return rc;
xen/common/grant_table.c __acquire_grant_for_copy( · line 2048
Quoted 5 lines
xen/common/grant_table.c +1
-0@@ -1994,6 +2044,7 @@ __acquire_grant_for_copy( {__fixup_status_for_copy_pin (act, status);rcu_unlock_domain (td); +active_entry_release (act);spin_unlock (&rgt->lock);
Please make the two sequences of unlocks the same.
xen/common/grant_table.c __acquire_grant_for_copy( · line 2131
Quoted 7 lines
xen/common/grant_table.c +3
-0@@ -2074,7 +2126,11 @@ __acquire_grant_for_copy(gnttab_clear_flag (_GTF_reading, status); unlock_out: +active_entry_release (act); + + gnt_unlock_out:
I think this would better be gt_unlock_out or gnttab_unlock_out.
Jan
Re: [PATCHv9 1/4] gnttab: per-active entry locking
Quoted 10 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 733
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +1
-0@@ -702,6 +729,7 @@ __gnttab_map_grant_ref( cache_flags = (shah->flags & (GTF_PAT |GTF_PWT |GTF_PCD ) ); +active_entry_release (act);spin_unlock (&rgt->lock);Just for my understanding: The lock isn't meant to also cover *shah? I.e. it could be dropped ahead of the
cache_flagsassignment?
I think so, but I think it's preferable (for now) to keep the locked regions as-is where possible.
There are few other places where it looked like the locked regions can be reduced. It won't really make much difference though since the read lock and active entry locks are not contented.
Quoted 7 lines
Quoted 7 lines
xen/common/grant_table.c +1
-1@@ -978,7 +1009,7 @@ __gnttab_unmap_common(if ( (rc =replace_grant_host_mapping (op->host_addr, op->frame, op->new_addr, op->flags)) <0 ) - goto unmap_out; + goto act_release_out;
Quoted 9 lines
xen/common/grant_table.c __gnttab_unmap_common( · line 1015
Quoted 2 lines
xen/common/grant_table.c +0
-0ASSERT (act->pin & (GNTPIN_hstw_mask | GNTPIN_hstr_mask)); op->map->flags &= ~GNTMAP_host_map;act doesn't look to be accessed anymore after the
if()this is contained in - why don't you drop the lock as early as possible? Or wait - do we needact->pinto remain stable until after that subsequentif()(in which case dropping the lock before the finalif()in the function would mainly make error handling more cumbersome without bying us much)?
See comment above.
David
PATCH v9 2/4 gnttab: introduce maptrack lock
In reply to David VrabelSplit grant table lock into two separate locks. One to protect maptrack state (maptrack_lock) and one for everything else (lock).
Based on a patch originally by Matt Wilson <[email protected]>.
--- docs/misc/grant-tables.txt | 9 +++++++++ xen/common/grant_table.c | 9 +++++---- xen/include/xen/grant_table.h | 2 ++ 3 files changed, 16 insertions(+), 4 deletions(-)
docs/misc/grant-tables.txt +9 -0
@@ -87,6 +87,7 @@ is complete. inconsistent grant table state such as current version, partially initialized active table pages, etc. + grant_table->maptrack_lock : spinlock used to protect the maptrack state active_grant_entry->lock : spinlock used to serialize modifications to active entries
@@ -94,6 +95,14 @@ is complete. that access members of struct grant_table must acquire the lock around critical sections. + The maptrack state is protected by its own spinlock. Any access (read + or write) of struct grant_table members that have a "maptrack_" + prefix must be made while holding the maptrack lock. The maptrack + state can be rapidly modified under some workloads, and the critical + sections are very small, thus we use a spinlock to protect them. + + The maptrack lock may be locked while holding the grant table lock. + Active entries are obtained by calling active_entry_acquire(gt, ref). This function returns a pointer to the active entry after locking its spinlock. The caller must hold the grant table lock for the gt in
xen/common/grant_table.c +5 -4
@@ -288,10 +288,10 @@ static inline void put_maptrack_handle( struct grant_table *t, int handle) { -spin_lock (&t->lock); +spin_lock (&t->maptrack_lock);maptrack_entry (t, handle).ref = t->maptrack_head; t->maptrack_head = handle; -spin_unlock (&t->lock); +spin_unlock (&t->maptrack_lock); } static inline int
@@ -303,7 +303,7 @@ get_maptrack_handle(struct grant_mapping *new_mt;unsigned int new_mt_limit, nr_frames; -spin_lock (&lgt->lock); +spin_lock (&lgt->maptrack_lock);while (unlikely ((handle =__get_maptrack_handle (lgt)) ==-1 ) ) {
@@ -332,7 +332,7 @@ get_maptrack_handle( nr_frames + 1); } -spin_unlock (&lgt->lock); +spin_unlock (&lgt->maptrack_lock);return handle; }
@@ -3005,6 +3005,7 @@ grant_table_create(/* Simple stuff. */ spin_lock_init (&t->lock); +spin_lock_init (&t->maptrack_lock); t->nr_grant_frames =INITIAL_NR_GRANT_FRAMES ;/* Active grant table. */
xen/include/xen/grant_table.h +2 -0
@@ -82,6 +82,8 @@ struct grant_table {struct grant_mapping **maptrack;unsigned int maptrack_head;unsigned int maptrack_limit; +/* Lock protecting the maptrack page list, head, and limit */ +spinlock_t maptrack_lock;/* Lock protecting updates to active and shared grant tables. */ spinlock_t lock;/* The defined versions are 1 and 2. Set to 0 if we don't know
Signature · 1 line
1.7.10.4
PATCH v9 3/4 gnttab: make the grant table lock a read-write lock
In reply to David VrabelIn combination with the per-active entry locks, the grant table lock can be made a read-write lock since the majority of cases only the read lock is required. The grant table read lock protects against changes to the table version or size (which are done with the write lock held).
The write lock is also required when two active entries must be acquired.
The double lock is still required when updating IOMMU page tables.
With the lock contention being only on the maptrack lock (unless IOMMU updates are required), performance and scalability is improved.
Based on a patch originally by Matt Wilson <[email protected]>.
--- docs/misc/grant-tables.txt | 30 +++++---- xen/arch/arm/mm.c | 4 +- xen/arch/x86/mm.c | 4 +- xen/common/grant_table.c | 148 ++++++++++++++++++++++------------------- xen/include/xen/grant_table.h | 9 ++- 5 files changed, 105 insertions(+), 90 deletions(-)
docs/misc/grant-tables.txt +17 -13
@@ -83,7 +83,7 @@ is complete. ~~~~~~~ Xen uses several locks to serialize access to the internal grant table state. - grant_table->lock : lock used to prevent readers from accessing + grant_table->lock : rwlock used to prevent readers from accessing inconsistent grant table state such as current version, partially initialized active table pages, etc.
@@ -91,9 +91,13 @@ is complete. active_grant_entry->lock : spinlock used to serialize modifications to active entries - The primary lock for the grant table is a spinlock. All functions - that access members of struct grant_table must acquire the lock - around critical sections. + The primary lock for the grant table is a read/write spinlock. All + functions that access members of struct grant_table must acquire a + read lock around critical sections. Any modification to the members + of struct grant_table (e.g., nr_status_frames, nr_grant_frames, + active frames, etc.) must only be made if the write lock is + held. These elements are read-mostly, and read critical sections can + be large, which makes a rwlock a good choice. The maptrack state is protected by its own spinlock. Any access (read or write) of struct grant_table members that have a "maptrack_"
@@ -105,25 +109,25 @@ is complete. Active entries are obtained by calling active_entry_acquire(gt, ref). This function returns a pointer to the active entry after locking its - spinlock. The caller must hold the grant table lock for the gt in - question before calling active_entry_acquire(). This is because the - grant table can be dynamically extended via gnttab_grow_table() while - a domain is running and must be fully initialized. Once all access to - the active entry is complete, release the lock by calling + spinlock. The caller must hold the grant table read lock before + calling active_entry_acquire(). This is because the grant table can + be dynamically extended via gnttab_grow_table() while a domain is + running and must be fully initialized. Once all access to the active + entry is complete, release the lock by calling active_entry_release(act). Summary of rules for locking: active_entry_acquire() and active_entry_release() can only be - called when holding the relevant grant table's lock. I.e.: - spin_lock(>->lock); + called when holding the relevant grant table's read lock. I.e.: + read_lock(>->lock); act = active_entry_acquire(gt, ref); ... active_entry_release(act); - spin_unlock(>->lock); + read_unlock(>->lock); Active entries cannot be acquired while holding the maptrack lock. Multiple active entries can be acquired while holding the grant table - lock. + _write_ lock. ********************************************************************************
xen/arch/arm/mm.c +2 -2
@@ -1048,7 +1048,7 @@ int xenmem_add_to_physmap_one(switch ( space ) {case XENMAPSPACE_grant_table: -spin_lock (&d->grant_table->lock); +write_lock (&d->grant_table->lock);if ( d->grant_table->gt_version ==0 ) d->grant_table->gt_version =1 ;
@@ -1078,7 +1078,7 @@ int xenmem_add_to_physmap_one( t = p2m_ram_rw; -spin_unlock (&d->grant_table->lock); +write_unlock (&d->grant_table->lock);break ;case XENMAPSPACE_shared_info:if ( idx !=0 )
xen/arch/x86/mm.c +2 -2
@@ -4593,7 +4593,7 @@ int xenmem_add_to_physmap_one( mfn =virt_to_mfn (d->shared_info);break ;case XENMAPSPACE_grant_table: -spin_lock (&d->grant_table->lock); +write_lock (&d->grant_table->lock);if ( d->grant_table->gt_version ==0 ) d->grant_table->gt_version =1 ;
@@ -4615,7 +4615,7 @@ int xenmem_add_to_physmap_one( mfn =virt_to_mfn (d->grant_table->shared_raw[idx]); } -spin_unlock (&d->grant_table->lock); +write_unlock (&d->grant_table->lock);break ;case XENMAPSPACE_gmfn_range:case XENMAPSPACE_gmfn:
xen/common/grant_table.c +78 -70
481 lines not on this page · raw message
xen/include/xen/grant_table.h +6 -3
@@ -64,6 +64,11 @@ struct grant_mapping {/* Per-domain grant information. */ struct grant_table { +/* +* Lock protecting updates to grant table state (version, active +* entry list, etc.) +*/ +rwlock_t lock;/* Table size. Number of frames shared with guest */ unsigned int nr_grant_frames;/* Shared grant table (see include/public/grant_table.h). */
@@ -84,8 +89,6 @@ struct grant_table {unsigned int maptrack_limit;/* Lock protecting the maptrack page list, head, and limit */ spinlock_t maptrack_lock; -/* Lock protecting updates to active and shared grant tables. */ -spinlock_t lock;/* The defined versions are 1 and 2. Set to 0 if we don't know what version to use yet. */ unsigned gt_version;
@@ -103,7 +106,7 @@ gnttab_release_mappings( struct domain *d);/* Increase the size of a domain's grant table. -* Caller must hold d's grant table lock. +* Caller must hold d's grant table write lock. */ int gnttab_grow_table (struct domain *d,unsigned int req_nr_frames);
Signature · 1 line
1.7.10.4
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 9 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-2@@ -254,23 +254,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) {if ( lgt < rgt ) { -spin_lock (&lgt->lock); -spin_lock (&rgt->lock); +write_lock (&lgt->lock); +write_lock (&rgt->lock);
xen/common/grant_table.c double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) · line 266
Quoted 10 lines
xen/common/grant_table.c +2
-2}else {if ( lgt != rgt ) -spin_lock (&rgt->lock); -spin_lock (&lgt->lock); +write_lock (&rgt->lock); +write_lock (&lgt->lock); } }
Do both of them need to be write locks now?
Quoted 17 lines
xen/common/grant_table.c +3
-2@@ -806,12 +806,13 @@ __gnttab_map_grant_ref( goto undo_out; } -double_gt_lock (lgt, rgt); -if (gnttab_need_iommu_mapping (ld) ) {unsigned int wrc, rdc;int err =0 ; + +double_gt_lock (lgt, rgt); +/* We're not translated, so we know that gmfns and mfns are the same things, so the IOMMU entry is always 1-to-1. */ mapcount (lgt, rd, frame, &wrc, &rdc);
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 5 lines
xen/common/grant_table.c +2
-0@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 ) err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);
unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
xen/common/grant_table.c __gnttab_map_grant_ref( · line 845
Quoted 5 lines
xen/common/grant_table.c +0
-1@@ -842,8 +845,6 @@ __gnttab_map_grant_ref( mt->ref = op->ref; mt->flags = op->flags; -double_gt_unlock (lgt, rgt);
Don't the mt-> updates above need some kind of protection?
Quoted 10 lines
xen/common/grant_table.c +1
-1@@ -2645,7 +2653,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)struct active_grant_entry *act_b =NULL ;s16 rc = GNTST_okay; -spin_lock (>->lock); +write_lock (>->lock);/* Bounds check on the grant refs */ if (unlikely (ref_a >=nr_grant_entries (d->grant_table)))
xen/common/grant_table.c out: · line 2700
Quoted 5 lines
xen/common/grant_table.c +1
-1@@ -2689,7 +2697,7 @@ out:active_entry_release (act_b);if ( act_a !=NULL )active_entry_release (act_a); -spin_unlock (>->lock); +write_unlock (>->lock);
With the per-entry locks, does this still o be a write lock?
Jan
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 13 lines · Jan Beulich
Quoted 13 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-2@@ -254,23 +254,23 @@ double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) {if ( lgt < rgt ) { -spin_lock (&lgt->lock); -spin_lock (&rgt->lock); +write_lock (&lgt->lock); +write_lock (&rgt->lock); }else {if ( lgt != rgt )
Quoted 8 lines
xen/common/grant_table.c double_gt_lock(struct grant_table *lgt, struct grant_table *rgt) · line 266
Quoted 6 lines
xen/common/grant_table.c +2
-2-spin_lock (&rgt->lock); -spin_lock (&lgt->lock); +write_lock (&rgt->lock); +write_lock (&lgt->lock); } }Do both of them need to be write locks now?
I don't know. This isn't used in any path I care about so I didn't spend any time on analysing it and did the obviously correct change.
Someone who cares about the performance of this path is going to have to do the work to further improve performance.
Quoted 18 lines
Quoted 18 lines
xen/common/grant_table.c +3
-2@@ -806,12 +806,13 @@ __gnttab_map_grant_ref( goto undo_out; } -double_gt_lock (lgt, rgt); -if (gnttab_need_iommu_mapping (ld) ) {unsigned int wrc, rdc;int err =0 ; + +double_gt_lock (lgt, rgt); +/* We're not translated, so we know that gmfns and mfns are the same things, so the IOMMU entry is always 1-to-1. */ mapcount (lgt, rd, frame, &wrc, &rdc);@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 )
Quoted 8 lines
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 4 lines
xen/common/grant_table.c +2
-0err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
I think it will be no worse than what it was before -- this path already really sucks (mapcount() loops over 1000s of entries). I don't care about this path at all.
Quoted 7 lines
xen/common/grant_table.c __gnttab_map_grant_ref( · line 845
Quoted 5 lines
xen/common/grant_table.c +0
-1@@ -842,8 +845,6 @@ __gnttab_map_grant_ref( mt->ref = op->ref; mt->flags = op->flags; -double_gt_unlock (lgt, rgt);Don't the mt-> updates above need some kind of protection?
It depends:
If not gnttab_need_iommu_mapping() but we only need a write barrier before the mt->flags store.
If gnttab_need_iommu_mapping() then a lock is required to prevent racing with concurrent mapcount() calls. This is not a path I care about so its easiest to just keep the double lock around this.
Quoted 7 lines
Quoted 7 lines
xen/common/grant_table.c +1
-1@@ -2645,7 +2653,7 @@ __gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)struct active_grant_entry *act_b =NULL ;s16 rc = GNTST_okay; -spin_lock (>->lock); +write_lock (>->lock);
Quoted 10 lines
xen/common/grant_table.c out: · line 2700
Quoted 8 lines
xen/common/grant_table.c +1
-1/* Bounds check on the grant refs */ if (unlikely (ref_a >=nr_grant_entries (d->grant_table)))@@ -2689,7 +2697,7 @@ out:active_entry_release (act_b);if ( act_a !=NULL )active_entry_release (act_a); -spin_unlock (>->lock); +write_unlock (>->lock);With the per-entry locks, does this still o be a write lock?
Yes, because we take two active entry locks and requiring the write lock is easier than ordering the active_entry_acquire()s.
Again, this isn't a path I care about.
David
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 10 lines · David Vrabel
Quoted 8 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 845
Quoted 6 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +0
-1@@ -842,8 +845,6 @@ __gnttab_map_grant_ref( mt->ref = op->ref; mt->flags = op->flags; -double_gt_unlock (lgt, rgt);Don't the mt-> updates above need some kind of protection?
Quoted 8 lines
It depends:
If not
gnttab_need_iommu_mapping()but we only need a write barrier before themt->flagsstore.If
gnttab_need_iommu_mapping()then a lock is required to prevent racing with concurrentmapcount()calls. This is not a path I care about so its easiest to just keep the double lock around this.
Like so:
@@ -806,12 +806,13 @@ __gnttab_map_grant_ref(
goto undo_out;
}- double_gt_lock(lgt, rgt);
-
if ( gnttab_need_iommu_mapping(ld) )
{
unsigned int wrc, rdc;
int err = 0;
+
+ double_gt_lock(lgt, rgt);
+
/* We're not translated, so we know that gmfns and mfns are
the same things, so the IOMMU entry is always 1-to-1. */
mapcount(lgt, rd, frame, &wrc, &rdc);@@ -837,12 +838,22 @@ __gnttab_map_grant_ref(
TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
+ /*
+ * All maptrack entry users check mt->flags first before using the
+ * other fields so just ensure the flags field is stored last.
+ *
+ * However, if gnttab_need_iommu_mapping() then this would race
+ * with a concurrent mapcount() call (on an unmap, for example)
+ * and a lock is required.
+ */
mt = &maptrack_entry(lgt, handle);
mt->domid = op->dom;
mt->ref = op->ref;
- mt->flags = op->flags;
+ wmb();
+ write_atomic(&mt->flags, op->flags);- double_gt_unlock(lgt, rgt);
+ if ( gnttab_need_iommu_mapping(ld) )
+ double_gt_unlock(lgt, rgt);
op->dev_bus_addr = (u64)frame << PAGE_SHIFT;
op->handle = handle;David
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
In reply to David VrabelQuoted 14 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 15:36, <[email protected]> wrote:
Quoted 11 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-0@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 ) err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
Quoted 3 lines
I think it will be no worse than what it was before -- this path already really sucks (
mapcount()loops over 1000s of entries). I don't care about this path at all.
It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be).
Jan
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 14 lines · Jan Beulich
Quoted 14 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 15:36, <[email protected]> wrote:
Quoted 11 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-0@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 ) err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
Quoted 7 lines
Quoted 3 lines
I think it will be no worse than what it was before -- this path already really sucks (
mapcount()loops over 1000s of entries). I don't care about this path at all.It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be).
What's your point? Are you going to refuse this series unless it also optimizes dom0-strict mode?
David
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 20 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 17:16, <[email protected]> wrote:
Quoted 18 lines · Jan Beulich
Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 15:36, <[email protected]> wrote:
Quoted 11 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-0@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 ) err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
I think it will be no worse than what it was before -- this path already really sucks (
mapcount()loops over 1000s of entries). I don't care about this path at all.
Quoted 6 lines
Quoted 3 lines
It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be).
What's your point? Are you going to refuse this series unless it also optimizes dom0-strict mode?
No, I'm certainly not going to be. But this series of "I don't care" worry me to a certain degree (apart from making me wonder why, as so far I thought an as secure as possible environment is key for XenServer, and "iommu=dom0-strict" is certainly helping with that, which is also why I said that this should arguably become the default).
Jan
Re: [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
Quoted 27 lines · Jan Beulich
Quoted 20 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 17:16, <[email protected]> wrote:
Quoted 18 lines · Jan Beulich
Quoted 17 lines
Quoted 1 line
Quoted 1 line · On 21.05.15 at 15:36, <[email protected]> wrote:
Quoted 11 lines · Jan Beulich
xen/common/grant_table.c __gnttab_map_grant_ref( · line 832
Quoted 7 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
xen/common/grant_table.c +2
-0@@ -827,9 +828,11 @@ __gnttab_map_grant_ref(if ( (wrc + rdc) ==0 ) err =iommu_map_page (ld, frame, frame, IOMMUF_readable); } + +double_gt_lock (lgt, rgt);unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like?
I think it will be no worse than what it was before -- this path already really sucks (
mapcount()loops over 1000s of entries). I don't care about this path at all.Quoted 6 lines
Quoted 3 lines
It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be).
What's your point? Are you going to refuse this series unless it also optimizes dom0-strict mode?
Quoted 6 lines
No, I'm certainly not going to be. But this series of "I don't care" worry me to a certain degree (apart from making me wonder why, as so far I thought an as secure as possible environment is key for XenServer, and "iommu=dom0-strict" is certainly helping with that, which is also why I said that this should arguably become the default).
dom0-strict mode doesn't align with our PV-IOMMU plans to make BFN == PFN (including for grants).
David
PATCH v9 4/4 gnttab: use per-VCPU maptrack free lists
In reply to David VrabelFrom: Malcolm Crossley <[email protected]>
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.
--- xen/common/grant_table.c | 139 ++++++++++++++++++++++++++--------------- xen/include/xen/grant_table.h | 8 ++- xen/include/xen/sched.h | 5 ++ 3 files changed, 97 insertions(+), 55 deletions(-)
xen/common/grant_table.c +87 -52
@@ -118,9 +118,9 @@ struct gnttab_unmap_common { ((t)->maptrack[(e)/MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])static inline unsigned int -nr_maptrack_frames (struct grant_table *t) +nr_vcpu_maptrack_frames (struct vcpu *v) { -return t->maptrack_limit /MAPTRACK_PER_PAGE ; +return v->maptrack_limit /MAPTRACK_PER_PAGE ; }#define MAPTRACK_TAIL (~0u)
@@ -275,66 +275,101 @@ double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)static inline int __get_maptrack_handle ( -struct grant_table *t) +struct grant_table *t, +struct vcpu *v) { -unsigned int h; -if (unlikely ((h = t->maptrack_head) ==MAPTRACK_TAIL ) ) +unsigned int head, next; + +/* No maptrack pages allocated for this VCPU yet? */ + head = v->maptrack_head; +if (unlikely (head ==MAPTRACK_TAIL ) ) +return -1 ; + +/* +* Always keep one entry in the free list to make it easier to add +* free entries to the tail. +*/ + next =read_atomic (&maptrack_entry (t, head).ref); +if (unlikely (next ==MAPTRACK_TAIL ) )return -1 ; - t->maptrack_head =maptrack_entry (t, h).ref; -return h; + + v->maptrack_head = next; + +return head; }static inline void put_maptrack_handle (struct grant_table *t,int handle) { -spin_lock (&t->maptrack_lock); -maptrack_entry (t, handle).ref = t->maptrack_head; - t->maptrack_head = handle; -spin_unlock (&t->maptrack_lock); +struct domain *d = current->domain; +struct vcpu *v; +unsigned int prev_tail, cur_tail; + +/* 1. Set entry to be a tail. */ +maptrack_entry (t, handle).ref =MAPTRACK_TAIL ; + +/* 2. Add entry to the tail of the list on the original VCPU. */ + v = d->vcpu[maptrack_entry (t,handle).vcpu]; + + cur_tail =read_atomic (&v->maptrack_tail); +do { + prev_tail = cur_tail; + cur_tail =cmpxchg (&v->maptrack_tail, prev_tail, handle); + }while ( cur_tail != prev_tail ); + +/* 3. Update the old tail entry to point to the new entry. */ +write_atomic (&maptrack_entry (t, prev_tail).ref, handle); }static inline int get_maptrack_handle (struct grant_table *lgt) { +struct vcpu *v = current;int i;grant_handle_t handle;struct grant_mapping *new_mt; -unsigned int new_mt_limit, nr_frames; +unsigned int nr_frames; -spin_lock (&lgt->maptrack_lock); + handle =__get_maptrack_handle (lgt, v); +if (likely (handle !=-1 ) ) +return handle; -while (unlikely ((handle =__get_maptrack_handle (lgt)) ==-1 ) ) - { - nr_frames =nr_maptrack_frames (lgt); -if ( nr_frames >= max_maptrack_frames ) -break ; + nr_frames =nr_vcpu_maptrack_frames (v); +if ( nr_frames >= max_maptrack_frames ) +return -1 ; - new_mt =alloc_xenheap_page (); -if ( !new_mt ) -break ; + new_mt =alloc_xenheap_page (); +if ( !new_mt ) +return -1 ; +clear_page (new_mt); -clear_page (new_mt); +spin_lock (&lgt->maptrack_lock); - new_mt_limit = lgt->maptrack_limit +MAPTRACK_PER_PAGE ; +for ( i =1 ; i <MAPTRACK_PER_PAGE ; i++ ) + { + new_mt[i -1 ].ref = (lgt->maptrack_pages *MAPTRACK_PER_PAGE ) + i; + new_mt[i -1 ].vcpu = v->vcpu_id; + } +/* Set last entry vcpu and ref */ + new_mt[i -1 ].ref = v->maptrack_head; + new_mt[i -1 ].vcpu = v->vcpu_id; -for ( i =1 ; i <MAPTRACK_PER_PAGE ; i++ ) - new_mt[i -1 ].ref = lgt->maptrack_limit + i; - new_mt[i -1 ].ref = lgt->maptrack_head; - lgt->maptrack_head = lgt->maptrack_limit; + v->maptrack_head = lgt->maptrack_pages *MAPTRACK_PER_PAGE ; - lgt->maptrack[nr_frames] = new_mt; -smp_wmb (); - lgt->maptrack_limit = new_mt_limit; +/* Set tail directly if this is the first page for this VCPU. */ +if ( v->maptrack_tail ==MAPTRACK_TAIL ) + v->maptrack_tail = (lgt->maptrack_pages *MAPTRACK_PER_PAGE ) + +MAPTRACK_PER_PAGE -1 ; -gdprintk (XENLOG_INFO ,"Increased maptrack size to %u frames\n" , - nr_frames +1 ); - } + lgt->maptrack[lgt->maptrack_pages++] = new_mt;spin_unlock (&lgt->maptrack_lock); -return handle; + v->maptrack_limit +=MAPTRACK_PER_PAGE ; + +return __get_maptrack_handle (lgt, v); }/* Number of grant table entries. Caller must hold d's grant table lock. */
@@ -573,7 +608,8 @@ static void mapcount(*/ ASSERT (rw_is_write_locked (&rd->grant_table->lock)); -for ( handle =0 ; handle < lgt->maptrack_limit; handle++ ) +for ( handle =0 ; handle < lgt->maptrack_pages *MAPTRACK_PER_PAGE ; + handle++ ) { map = &maptrack_entry (lgt, handle); if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) ||
@@ -931,7 +967,7 @@ __gnttab_unmap_common( op->frame = (unsigned long )(op->dev_bus_addr >>PAGE_SHIFT ); -if (unlikely (op->handle >= lgt->maptrack_limit) ) +if (unlikely (op->handle >= lgt->maptrack_pages *MAPTRACK_PER_PAGE ) ) {gdprintk (XENLOG_INFO ,"Bad handle (%d).\n" , op->handle); op->status = GNTST_bad_handle;
@@ -1406,6 +1442,7 @@ gnttab_setup_table(struct gnttab_setup_table op;struct domain *d;struct grant_table *gt; +struct vcpu *v;int i;xen_pfn_t gmfn;
@@ -1447,6 +1484,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; +for_each_vcpu ( d, v ) + { + v->maptrack_head =MAPTRACK_TAIL ; + v->maptrack_tail =MAPTRACK_TAIL ; + } + gt->maptrack_pages =0 ; +if ( gt->gt_version ==0 ) gt->gt_version =1 ;
@@ -3030,18 +3078,6 @@ grant_table_create(spin_lock_init (&t->active[i][j].lock); } -/* Tracking of mapped foreign frames table */ - if ( (t->maptrack = xzalloc_array(struct grant_mapping *, - max_maptrack_frames)) ==NULL ) - goto no_mem_2; -if ( (t->maptrack[0 ] =alloc_xenheap_page ()) ==NULL ) - goto no_mem_3; -clear_page (t->maptrack[0 ]); - t->maptrack_limit =MAPTRACK_PER_PAGE ; -for ( i =1 ; i <MAPTRACK_PER_PAGE ; i++ ) - t->maptrack[0 ][i -1 ].ref = i; - t->maptrack[0 ][i -1 ].ref =MAPTRACK_TAIL ; -/* Shared grant table. */ if ( (t->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL ) goto no_mem_3;
@@ -3072,8 +3108,6 @@ grant_table_create(free_xenheap_page (t->shared_raw[i]);xfree (t->shared_raw); no_mem_3: -free_xenheap_page (t->maptrack[0 ]); -xfree (t->maptrack); no_mem_2:for ( i =0 ; i <num_act_frames_from_sha_frames (INITIAL_NR_GRANT_FRAMES ); i++ )
@@ -3101,7 +3135,8 @@ gnttab_release_mappings(BUG_ON (!d->is_dying); -for ( handle =0 ; handle < gt->maptrack_limit; handle++ ) +for ( handle =0 ; handle < gt->maptrack_pages *MAPTRACK_PER_PAGE ; + handle++ ) { map = &maptrack_entry (gt, handle);if ( !(map->flags & (GNTMAP_device_map|GNTMAP_host_map)) )
@@ -3206,7 +3241,7 @@ grant_table_destroy(free_xenheap_page (t->shared_raw[i]);xfree (t->shared_raw); -for ( i =0 ; i <nr_maptrack_frames (t); i++ ) +for ( i =0 ; i < t->maptrack_pages; i++ )free_xenheap_page (t->maptrack[i]);xfree (t->maptrack);
xen/include/xen/grant_table.h +5 -3
@@ -60,6 +60,8 @@ struct grant_mapping {u32 ref;/* grant ref */ u16 flags;/* 0-4: GNTMAP_* ; 5-15: unused */ domid_t domid;/* granting domain */ +u32 vcpu;/* vcpu which created the grant mapping */ +u32 pad;/* round size to a power of 2 */ };/* Per-domain grant information. */
@@ -83,10 +85,10 @@ struct grant_table {grant_status_t **status;/* Active grant table. */ struct active_grant_entry **active; -/* Mapping tracking table. */ +/* Mapping tracking table per vcpu. */ struct grant_mapping **maptrack; -unsigned int maptrack_head; -unsigned int maptrack_limit; +/* Total pages used for mapping tracking table */ +unsigned int maptrack_pages;/* Lock protecting the maptrack page list, head, and limit */ spinlock_t maptrack_lock;/* The defined versions are 1 and 2. Set to 0 if we don't know
xen/include/xen/sched.h +5 -0
@@ -219,6 +219,11 @@ struct vcpu/* VCPU paused by system controller. */ int controller_pause_count; +/* Maptrack */ +unsigned int maptrack_head; +unsigned int maptrack_tail; +unsigned int maptrack_limit; +/* IRQ-safe virq_lock protects against delivering VIRQ to stale evtchn. */ evtchn_port_t virq_to_evtchn[NR_VIRQS ];spinlock_t virq_lock;
Signature · 1 line
1.7.10.4
Re: [PATCHv9 4/4] gnttab: use per-VCPU maptrack free lists
Quoted 14 lines
Quoted 1 line
Quoted 1 line · On 20.05.15 at 17:54, <[email protected]> wrote:
static inline int
get_maptrack_handle(
structgrant_table*lgt)
{xen/common/grant_table.c +3
-2+struct vcpu *v = current;int i;grant_handle_t handle;struct grant_mapping *new_mt; -unsigned int new_mt_limit, nr_frames; +unsigned int nr_frames; -spin_lock (&lgt->maptrack_lock); + handle =__get_maptrack_handle (lgt, v);
xen/common/grant_table.c double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt) · line 340
Quoted 10 lines
xen/common/grant_table.c +4
-5+if (likely (handle !=-1 ) ) +return handle; -while (unlikely ((handle =__get_maptrack_handle (lgt)) ==-1 ) ) - { - nr_frames =nr_maptrack_frames (lgt); -if ( nr_frames >= max_maptrack_frames ) -break ; + nr_frames =nr_vcpu_maptrack_frames (v); +if ( nr_frames >= max_maptrack_frames )
I think you want to check lgt->maptrack_pages here, to make sure the global limit remains a per-domain one. Or else we'd need a dual (Dom0/DomU) or even per-domain bound to avoid many-vCPU guests being able to force Xen into using significant amounts of memory for their maptrack.
xen/common/grant_table.c gnttab_setup_table( · line 1490
Quoted 8 lines
xen/common/grant_table.c +4
-0@@ -1447,6 +1484,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;
Not that vzalloc() meanwhile exists. But depending on the resolution of the aspect above you may not even urgently need it here.
Jan