Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On Wed, 2015-03-25 at 13:34 -0400, Sowmini Varadhan wrote:
> 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.
>
.../...
>
> diff --git a/include/linux/iommu-common.h b/include/linux/iommu-common.h
> new file mode 100644
> index 000..197111b
> --- /dev/null
> +++ b/include/linux/iommu-common.h
> @@ -0,0 +1,48 @@
> +#ifndef _LINUX_IOMMU_COMMON_H
> +#define _LINUX_IOMMU_COMMON_H
> +
> +#include
> +#include
> +#include
> +
> +#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 ?
> +struct iommu_pool {
> + unsigned long start;
> + unsigned long end;
> + unsigned long hint;
> + spinlock_t lock;
> +};
> +
> +struct iommu_table {
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.
> + unsigned long page_table_map_base;
> + unsigned long page_table_shift;
Minor nit but I'm not fan of the naming here, maybe just use
entry_shift ? I don't like too long identifiers :) Same for
base, could just be "base" or "table_base".
> + unsigned long nr_pools;
> + void(*flush_all)(struct iommu_table *);
Call this "lazy_flush", document that it is optional and when it is
called.
> + unsigned long poolsize;
> + struct iommu_pool arena_pool[IOMMU_NR_POOLS];
Why adding the 'arena' prefix ? What was wrong with "pools" in the
powerpc imlementation ?
> + u32 flags;
> +#define IOMMU_HAS_LARGE_POOL0x0001
> +#define IOMMU_NO_SPAN_BOUND 0x0002
> + 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
> diff --git a/lib/Makefile b/lib/Makefile
> index 3c3b30b..0ea2ac6 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -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
> diff --git a/lib/iommu-common.c b/lib/iommu-common.c
> new file mode 100644
> index 000..bb7e706
> --- /dev/null
> +++ b/lib/iommu-common.c
> @@ -0,0 +1,235 @@
> +/*
> + * IOMMU mmap management and range allocation functions.
> + * Based almost entirely upon the powerpc iommu allocator.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define IOMMU_LARGE_ALLOC15
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.
> +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)
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On (03/30/15 14:24), Benjamin Herrenschmidt wrote:
> > +
> > +#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.
:
> 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 ?
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.
> > +#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.
> > + /* 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.
> 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.
--Sowmini
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On Mon, 2015-03-30 at 06:38 -0400, Sowmini Varadhan wrote:
> On (03/30/15 14:24), Benjamin Herrenschmidt wrote:
> > > +
> > > +#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.
Right, but it affects the way we hash... not a huge deal though.
>:
> > 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 ?
>
> 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.
But in that case it doesn't make much sense and makes the names longer.
Those are just "pools", it's sufficient.
> > > +#define IOMMU_LARGE_ALLOC15
> >
> > 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.
>
> > > + /* 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.
Put it back please, and ignore checkpatch, it's become an annoyance more
than anything else.
Note that nowadays, you can probably use WARN_ON_ONCE(npages == 0); in
place of the whole construct.
> > 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.
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.
> But yes, I did instrument it with iperf, and there was lock contention
> on the spinlock, which was eliminted by the trylock.
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.
> I'll fix the rest of the variable naming etc nits and send out
> a new version later today.
There was also an actual bug in the case where you hop'ed to a new pool
and forgot the flush.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On (03/30/15 21:55), Benjamin Herrenschmidt wrote: > > 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. 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. > 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. iperf is a network perf benchmark. I'll try to regenerate some numbers today and get some instrumentation of cache-line bounces vs trylock misses. > There was also an actual bug in the case where you hop'ed to a new pool > and forgot the flush. yes, thanks for catching that, I'll fix that too, of course. --Sowmini ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On (03/30/15 09:01), Sowmini Varadhan wrote: > > 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). --Sowmini ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On Mon, 2015-03-30 at 17:15 -0400, Sowmini Varadhan wrote:
> On (03/30/15 09:01), Sowmini Varadhan wrote:
> >
> > 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.
powerpc:
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
CLEAR_IO_SYNC;
while (1) {
if (likely(__arch_spin_trylock(lock) == 0))
break;
do {
HMT_low();
if (SHARED_PROCESSOR)
__spin_yield(lock);
} while (unlikely(lock->slock != 0));
HMT_medium();
}
}
The HMT_* statements are what reduces the thread prio. Additionally,
the yield thingy is something that allows us to relinguish out time
slice to the partition owning the lock if it's not currently scheduled
by the hypervisor.
> 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.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
On (03/31/15 08:28), Benjamin Herrenschmidt wrote: > > 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. sounds good. let me wait for the confirmation from IB, and I'll send out patchv8 soon after. FWIW, I'm ok with all the other comments- thanks for the feedback. --Sowmini ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
