Generic IOMMU pooled allocator

Changes from patchv6: moved pool_hash initialization to lib/iommu-common.c and cleaned up code duplication from sun4v/sun4u/ldc.

From: Sowmini Varadhan <[email protected]>
Date: Wed, 25 Mar 2015 13:34:45 -0400

Quoted 3 lines

Changes from patchv6: moved pool_hash initialization to lib/iommu-common.c and cleaned up code duplication from sun4v/sun4u/ldc.

Looks good to me.

PowerPC folks, what do you think?

Quoted 1 line

PowerPC folks, what do you think?

I'll give it another look today.

Cheers,
Ben.

Investigation of multithreaded iperf experiments on an ethernet interface show the iommu->lock as the hottest lock identified by lockstat, with something of the order of 21M contentions out of 27M acquisitions, and an average wait time of 26 us for the lock. This is not efficient. A more scalable design is to follow the ppc model, where the iommu_table has multiple pools, each stretching over a segment of the map, and with a separate lock for each pool. This model allows for better parallelization of the iommu map search.

include/linux/iommu-common.h new file +0 -0

new file mode 100644
index 0000000..197111b

include/linux/iommu-common.h new file +24 -0

+	u32			flags;
+#define	IOMMU_HAS_LARGE_POOL	0x00000001
+#define	IOMMU_NO_SPAN_BOUND	0x00000002
+	struct iommu_pool	large_pool;
+	unsigned long		*map;
+};
+
+extern void iommu_tbl_pool_init(struct iommu_table *iommu,
+				unsigned long num_entries,
+				u32 page_table_shift,
+				void (*flush_all)(struct iommu_table *),
+				bool large_pool, u32 npools,
+				bool skip_span_boundary_check);
+
+extern unsigned long iommu_tbl_range_alloc(struct device *dev,
+					   struct iommu_table *iommu,
+					   unsigned long npages,
+					   unsigned long *handle);
+
+extern void iommu_tbl_range_free(struct iommu_table *iommu,
+				 u64 dma_addr, unsigned long npages,
+				 unsigned long entry);
+
+#endif

lib/Makefile +1 -1

index 3c3b30b..0ea2ac6 100644
@@ -102,7 +102,7 @@ obj-$(CONFIG_AUDIT_GENERIC) += audit.o
 obj-$(CONFIG_AUDIT_COMPAT_GENERIC) += compat_audit.o
 
 obj-$(CONFIG_SWIOTLB) += swiotlb.o
-obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
+obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o iommu-common.o
 obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
 obj-$(CONFIG_NOTIFIER_ERROR_INJECTION) += notifier-error-inject.o
 obj-$(CONFIG_CPU_NOTIFIER_ERROR_INJECT) += cpu-notifier-error-inject.o

lib/iommu-common.c new file +4 -0

new file mode 100644
index 0000000..bb7e706
@@ -0,0 +1,235 @@
+/*
+ * IOMMU mmap management and range allocation functions.
+ * Based almost entirely upon the powerpc iommu allocator.
+ */

lib/iommu-common.c new file +75 -0

+static	DEFINE_PER_CPU(unsigned int, iommu_pool_hash);
+
+static void setup_iommu_pool_hash(void)
+{
+	unsigned int i;
+	static bool do_once;
+
+	if (do_once)
+		return;
+	do_once = true;
+	for_each_possible_cpu(i)
+		per_cpu(iommu_pool_hash, i) = hash_32(i, IOMMU_POOL_HASHBITS);
+}
+
+/*
+ * Initialize iommu_pool entries for the iommu_table. `num_entries'
+ * is the number of table entries. If `large_pool' is set to true,
+ * the top 1/4 of the table will be set aside for pool allocations
+ * of more than IOMMU_LARGE_ALLOC pages.
+ */
+extern void iommu_tbl_pool_init(struct iommu_table *iommu,
+				unsigned long num_entries,
+				u32 page_table_shift,
+				void (*flush_all)(struct iommu_table *),
+				bool large_pool, u32 npools,
+				bool skip_span_boundary_check)
+{
+	unsigned int start, i;
+	struct iommu_pool *p = &(iommu->large_pool);
+
+	setup_iommu_pool_hash();
+	if (npools = 0)
+		iommu->nr_pools = IOMMU_NR_POOLS;
+	else
+		iommu->nr_pools = npools;
+	BUG_ON(npools > IOMMU_NR_POOLS);
+
+	iommu->page_table_shift = page_table_shift;
+	iommu->flush_all = flush_all;
+	start = 0;
+	if (skip_span_boundary_check)
+		iommu->flags |= IOMMU_NO_SPAN_BOUND;
+	if (large_pool)
+		iommu->flags |= IOMMU_HAS_LARGE_POOL;
+
+	if (!large_pool)
+		iommu->poolsize = num_entries/iommu->nr_pools;
+	else
+		iommu->poolsize = (num_entries * 3 / 4)/iommu->nr_pools;
+	for (i = 0; i < iommu->nr_pools; i++) {
+		spin_lock_init(&(iommu->arena_pool[i].lock));
+		iommu->arena_pool[i].start = start;
+		iommu->arena_pool[i].hint = start;
+		start += iommu->poolsize; /* start for next pool */
+		iommu->arena_pool[i].end = start - 1;
+	}
+	if (!large_pool)
+		return;
+	/* initialize large_pool */
+	spin_lock_init(&(p->lock));
+	p->start = start;
+	p->hint = p->start;
+	p->end = num_entries;
+}
+EXPORT_SYMBOL(iommu_tbl_pool_init);
+
+unsigned long iommu_tbl_range_alloc(struct device *dev,
+				struct iommu_table *iommu,
+				unsigned long npages,
+				unsigned long *handle)
+{
+	unsigned int pool_hash = __this_cpu_read(iommu_pool_hash);
+	unsigned long n, end, start, limit, boundary_size;
+	struct iommu_pool *arena;
+	int pass = 0;

lib/iommu-common.c new file +8 -0

+ again:
+	if (pass = 0 && handle && *handle &&
+	    (*handle >= arena->start) && (*handle < arena->end))
+		start = *handle;
+	else
+		start = arena->hint;
+
+	limit = arena->end;

lib/iommu-common.c new file +27 -0

+
+	if (dev)
+		boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+				      1 << iommu->page_table_shift);
+	else
+		boundary_size = ALIGN(1UL << 32, 1 << iommu->page_table_shift);
+
+	shift = iommu->page_table_map_base >> iommu->page_table_shift;
+	boundary_size = boundary_size >> iommu->page_table_shift;
+	/*
+	 * if the skip_span_boundary_check had been set during init, we set
+	 * things up so that iommu_is_span_boundary() merely checks if the
+	 * (index + npages) < num_tsb_entries
+	 */
+	if ((iommu->flags & IOMMU_NO_SPAN_BOUND) != 0) {
+		shift = 0;
+		boundary_size = iommu->poolsize * iommu->nr_pools;
+	}
+	n = iommu_area_alloc(iommu->map, limit, start, npages, shift,
+			     boundary_size, 0);
+	if (n = -1) {
+		if (likely(pass = 0)) {
+			/* First failure, rescan from the beginning.  */
+			arena->hint = arena->start;
+			if (!large_pool && iommu->flush_all != NULL)
+				iommu->flush_all(iommu);
+			pass++;

lib/iommu-common.c new file +53 -0

+
+	end = n + npages;
+
+	arena->hint = end;
+
+	/* Update handle for SG allocations */
+	if (handle)
+		*handle = end;
+	spin_unlock_irqrestore(&(arena->lock), flags);
+
+	return n;
+}
+EXPORT_SYMBOL(iommu_tbl_range_alloc);
+
+static struct iommu_pool *get_pool(struct iommu_table *tbl,
+				   unsigned long entry)
+{
+	struct iommu_pool *p;
+	unsigned long largepool_start = tbl->large_pool.start;
+	bool large_pool = ((tbl->flags & IOMMU_HAS_LARGE_POOL) != 0);
+
+	/* The large pool is the last pool at the top of the table */
+	if (large_pool && entry >= largepool_start) {
+		p = &tbl->large_pool;
+	} else {
+		unsigned int pool_nr = entry / tbl->poolsize;
+
+		BUG_ON(pool_nr >= tbl->nr_pools);
+		p = &tbl->arena_pool[pool_nr];
+	}
+	return p;
+}
+
+/* Caller supplies the index of the entry into the iommu map table
+ * itself when the mapping from dma_addr to the entry is not the
+ * default addr->entry mapping below.
+ */
+void iommu_tbl_range_free(struct iommu_table *iommu, u64 dma_addr,
+			  unsigned long npages, unsigned long entry)
+{
+	struct iommu_pool *pool;
+	unsigned long flags;
+	unsigned long shift = iommu->page_table_shift;
+
+	if (entry = DMA_ERROR_CODE) /* use default addr->entry mapping */
+		entry = (dma_addr - iommu->page_table_map_base) >> shift;
+	pool = get_pool(iommu, entry);
+
+	spin_lock_irqsave(&(pool->lock), flags);
+	bitmap_clear(iommu->map, entry, npages);
+	spin_unlock_irqrestore(&(pool->lock), flags);
+}
+EXPORT_SYMBOL(iommu_tbl_range_free);

include/linux/iommu-common.h line 9

Quoted 3 lines

include/linux/iommu-common.h new file +3 -0

+
+#define IOMMU_POOL_HASHBITS     4
+#define IOMMU_NR_POOLS          (1 << IOMMU_POOL_HASHBITS)

I don't like those macros. You changed the value from what we had on powerpc. It could be that the new values are as good for us but I'd like to do a bit differently. Can you make the bits a variable ? Or at least an arch-provided macro which we can change later if needed ?

Let's make it clear that this is for allocation of DMA space only, it would thus make my life easier when adapting powerpc to use a different names, something like "struct iommu_area" works for me, or "iommu alloc_region" .. whatever you fancy the most.

Why adding the 'arena' prefix ? What was wrong with "pools" in the powerpc imlementation ?

Quoted 1 line

+#define IOMMU_LARGE_ALLOC 15

Make that a variable, here too, the arch might want to tweak it.

I think 15 is actually not a good value for powerpc with 4k iommu pages and 64k PAGE_SIZE, we should make the above some kind of factor of PAGE_SHIFT - iommu_page_shift.

lib/iommu-common.c line 100

Quoted 3 lines

lib/iommu-common.c new file +3 -0

+	/* Sanity check */
+	if (unlikely(npages = 0)) {
+		printk_ratelimited("npages = 0\n");

You removed the WARN_ON here which had the nice property of giving you a backtrace which points to the offender. The above message alone is useless.

I am not certain about the "first unlocked pool"... We take the lock for a fairly short amount of time, I have the gut feeling that the cache line bouncing introduced by looking at a different pool may well cost more than waiting a bit longer. Did do some measurements of that optimisation ?

Quoted 8 lines · Benjamin Herrenschmidt

include/linux/iommu-common.h line 9

Quoted 3 lines

include/linux/iommu-common.h new file +3 -0

+
+#define IOMMU_POOL_HASHBITS     4
+#define IOMMU_NR_POOLS          (1 << IOMMU_POOL_HASHBITS)

I don't like those macros. You changed the value from what we had on powerpc. It could be that the new values are as good for us but I'd like to do a bit differently. Can you make the bits a variable ? Or at least an arch-provided macro which we can change later if needed ?

Actuallly, this are just the upper bound (16) on the number of pools.

The actual number is selected by the value passed to the iommu_tbl_range_init(), and is not hard-coded (as was the case with the power-pc code).

Thus powerpc can continue to use 4 pools without any loss of generality.

   :

Quoted 4 lines

Let's make it clear that this is for allocation of DMA space only, it would thus make my life easier when adapting powerpc to use a different names, something like "struct iommu_area" works for me, or "iommu alloc_region" .. whatever you fancy the most.

:

Quoted 2 lines

Why adding the 'arena' prefix ? What was wrong with "pools" in the powerpc imlementation ?

for the same reason you want to re-baptize iommu_table above- at the time, I was doing it to minimize conflicts with existing usage. But I can rename everything if you like.

Quoted 7 lines

Quoted 1 line

+#define IOMMU_LARGE_ALLOC 15

Make that a variable, here too, the arch might want to tweak it.

I think 15 is actually not a good value for powerpc with 4k iommu pages and 64k PAGE_SIZE, we should make the above some kind of factor of PAGE_SHIFT - iommu_page_shift.

Ok.

Quoted 7 lines

lib/iommu-common.c line 100

Quoted 3 lines

lib/iommu-common.c new file +3 -0

+	/* Sanity check */
+	if (unlikely(npages = 0)) {
+		printk_ratelimited("npages = 0\n");

You removed the WARN_ON here which had the nice property of giving you a backtrace which points to the offender. The above message alone is useless.

yes, the original code was generating checkpatch warnings and errors. That's why I removed it.

Quoted 5 lines

I am not certain about the "first unlocked pool"... We take the lock for a fairly short amount of time, I have the gut feeling that the cache line bouncing introduced by looking at a different pool may well cost more than waiting a bit longer. Did do some measurements of that optimisation ?

if you are really only taking it for a short amount of time, then the trylock should just succeed, so there is no cache line bouncing.

But yes, I did instrument it with iperf, and there was lock contention on the spinlock, which was eliminted by the trylock.

I'll fix the rest of the variable naming etc nits and send out a new version later today.

No that's not my point. The lock is only taken for a short time but might still collide, the bouncing in that case will probably (at least that's my feeling) hurt more than help.

However, I have another concern with your construct. Essentially you spin looking for an unlocked pool without a cpu_relax. Now it's unlikely but you *can* end up eating cycles, which on a high SMT like POWER8 might mean slowing down the actual owner of the pool lock.

What is iperf ? What does that mean "there was lock contention" ? IE, was the overall performance improved or not ? Removing contention by trading it for cache line bouncing will not necessarily help. I'm not saying this is a bad optimisation but it makes the code messy and I think deserves some solid numbers demonstrating its worth.

There was also an actual bug in the case where you hop'ed to a new pool and forgot the flush.

So I tried looking at the code, and perhaps there is some arch-specific subtlety here that I am missing, but where does spin_lock itself do the cpu_relax? afaict, LOCK_CONTENDED() itself does not have this.

Quoted 4 lines · Sowmini Varadhan

So I tried looking at the code, and perhaps there is some arch-specific subtlety here that I am missing, but where does spin_lock itself do the cpu_relax? afaict, LOCK_CONTENDED() itself does not have this.

To answer my question:
I'd missed the CONFIG_LOCK_STAT (which David Ahern pointed out to me). the above is only true for the LOCK_STAT case.

In any case, I ran some experiments today: I was running iperf [http://en.wikipedia.org/wiki/Iperf] over ixgbe, which is where I'd noticed the original perf issues for sparc. I was running iperf2 (which is more aggressively threaded than iperf3) with 8, 10, 16, 20 threads, and with TSO turned off. In each case, I was making sure that I was able to reach 9.X Gbps (this is a 10Gbps link)

I dont see any significant difference in the perf profile between the spin_trylock and the spin_lock version (other than, of course, the change to the lock-contention for the trylock version). I looked at the perf profiled cache-misses (works out to about 1400M for 10 threads, with or without the trylock).

I'm still waiting for some of the IB folks to try out the spin_lock version (they had also seen some significant perf improvements from breaking down the monolithic lock into multiple pools, so their workload is also sensitive to this)

But as such, it looks like it doesnt matter much, whether you use the trylock to find the first available pool, or block on the spin_lock. I'll let folks on this list vote on this one (assuming the IB tests also come out without a significant variation between the 2 locking choices).

Provided that the IB test doesn't come up with a significant difference, I definitely vote for the simpler version of doing a normal spin_lock.