From: Adam Morrison <mad-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org>
To: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: serebrin-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
dan-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org,
omer-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org,
shli-b10kYP2dOMg@public.gmane.org,
gvdl-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
Kernel-team-b10kYP2dOMg@public.gmane.org
Subject: [PATCH v3 0/7] Intel IOMMU scalability improvements
Date: Tue, 19 Apr 2016 19:48:16 +0300 [thread overview]
Message-ID: <cover.1460733778.git.mad@cs.technion.ac.il> (raw)
This patchset improves the scalability of the Intel IOMMU code by
resolving two spinlock bottlenecks, yielding up to ~5x performance
improvement and approaching iommu=off performance.
For example, here's the throughput obtained by 16 memcached instances
running on a 16-core Sandy Bridge system, accessed using memslap on
another machine that has iommu=off, using the default memslap config
(64-byte keys, 1024-byte values, and 10%/90% SET/GET ops):
stock iommu=off:
990,803 memcached transactions/sec (=100%, median of 10 runs).
stock iommu=on:
221,416 memcached transactions/sec (=22%).
[61.70% 0.63% memcached [kernel.kallsyms] [k] _raw_spin_lock_irqsave]
patched iommu=on:
963,159 memcached transactions/sec (=97%).
[1.29% 1.10% memcached [kernel.kallsyms] [k] _raw_spin_lock_irqsave]
The two resolved spinlocks:
- Deferred IOTLB invalidations are batched in a global data structure
and serialized under a spinlock (add_unmap() & flush_unmaps()); this
patchset batches IOTLB invalidations in a per-CPU data structure.
- IOVA management (alloc_iova() & __free_iova()) is serialized under
the rbtree spinlock; this patchset adds per-CPU caches of allocated
IOVAs so that the rbtree doesn't get accessed frequently. (Adding a
cache above the existing IOVA allocator is less intrusive than dynamic
identity mapping and helps keep IOMMU page table usage low; see
Patch 7.)
The paper "Utilizing the IOMMU Scalably" (presented at the 2015 USENIX
Annual Technical Conference) contains many more details and experiments:
https://www.usenix.org/system/files/conference/atc15/atc15-paper-peleg.pdf
v3:
* Patch 7/7: Respect the caller-passed limit IOVA when satisfying an IOVA
allocation from the cache.
* Patch 7/7: Flush the IOVA cache if an rbtree IOVA allocation fails, and
then retry the allocation. This addresses the possibility that all
desired IOVA ranges were in other CPUs' caches.
* Patch 4/7: Clean up intel_unmap_sg() to use sg accessors.
v2:
* Extend IOVA API instead of modifying it, to not break the API's other
non-Intel callers.
* Invalidate all per-cpu invalidations if one CPU hits its per-cpu limit,
so that we don't defer invalidations more than before.
* Smaller cap on per-CPU cache size, to consume less of the IOVA space.
* Free resources and perform IOTLB invalidations when a CPU is hot-unplugged.
Omer Peleg (7):
iommu: refactoring of deferred flush entries
iommu: per-cpu deferred invalidation queues
iommu: correct flush_unmaps pfn usage
iommu: only unmap mapped entries
iommu: avoid dev iotlb logic in intel-iommu for domains with no dev
iotlbs
iommu: change intel-iommu to use IOVA frame numbers
iommu: introduce per-cpu caching to iova allocation
drivers/iommu/intel-iommu.c | 318 +++++++++++++++++++++++----------
drivers/iommu/iova.c | 416 +++++++++++++++++++++++++++++++++++++++++---
include/linux/iova.h | 23 ++-
3 files changed, 637 insertions(+), 120 deletions(-)
--
1.9.1
next reply other threads:[~2016-04-19 16:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-19 16:48 Adam Morrison [this message]
[not found] ` <cover.1460733778.git.mad-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org>
2016-04-19 16:48 ` [PATCH v3 1/7] iommu: refactoring of deferred flush entries Adam Morrison
2016-04-19 16:48 ` [PATCH v3 2/7] iommu: per-cpu deferred invalidation queues Adam Morrison
2016-04-19 16:48 ` [PATCH v3 3/7] iommu: correct flush_unmaps pfn usage Adam Morrison
2016-04-19 16:49 ` [PATCH v3 4/7] iommu: only unmap mapped entries Adam Morrison
2016-04-19 16:49 ` [PATCH v3 5/7] iommu: avoid dev iotlb logic in intel-iommu for domains with no dev iotlbs Adam Morrison
[not found] ` <20d0571ab8dda05bd3980b18df0a810fb26480e4.1460733778.git.mad-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org>
2016-04-19 19:09 ` David Woodhouse
[not found] ` <1461092967.25115.7.camel-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-04-20 8:21 ` Adam Morrison
2016-04-19 16:49 ` [PATCH v3 6/7] iommu: change intel-iommu to use IOVA frame numbers Adam Morrison
2016-04-19 16:49 ` [PATCH v3 7/7] iommu: introduce per-cpu caching to iova allocation Adam Morrison
[not found] ` <0923752fb142601d6c2b58bcf7cdceea6ec9305e.1460733778.git.mad-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org>
2016-04-19 20:50 ` Benjamin Serebrin via iommu
2016-04-19 20:47 ` [PATCH v3 0/7] Intel IOMMU scalability improvements Shaohua Li
[not found] ` <20160419204705.GA1134028-tb7CFzD8y5b7E6g3fPdp/g2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2016-04-19 20:52 ` Benjamin Serebrin via iommu
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=cover.1460733778.git.mad@cs.technion.ac.il \
--to=mad-fresstt7abv7r6psnubssmzhpeb/a1y/@public.gmane.org \
--cc=Kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=dan-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=gvdl-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=omer-FrESSTt7Abv7r6psnUbsSmZHpeb/A1Y/@public.gmane.org \
--cc=serebrin-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=shli-b10kYP2dOMg@public.gmane.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