From: Shaohua Li
I made a mistake in commit bfd20f1. We should skip the force on with the
option enabled instead of vice versa. Not sure why this passed our
performance test, sorry.
Fix: bfd20f1(x86, iommu/vt-d: Add an option to disable Intel IOMMU force on)
Signed-off-by: Shaohua Li
---
arch
ave 2 caches, one for DMA32
and the other for DMA64. Mixing them in one cache might make allocation
from cache have more failure. But we can do this later if it is a real
problem. So for the the whole series
Reviewed-by: Shaohua Li
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Apr 14, 2016 at 09:59:39PM -0700, Benjamin Serebrin wrote:
> On Thu, Apr 14, 2016 at 2:33 PM, Shaohua Li wrote:
>
> > On Thu, Apr 14, 2016 at 02:18:32PM -0700, Benjamin Serebrin wrote:
> > > On Thu, Apr 14, 2016 at 2:05 PM, Adam Morrison
> > wrote:
> >
ng the normal case?
>
> > It's tempting to make the rcaches work only for DMA_64 allocations.
> > This would also solve the problem of respecting the pfn_limit when
> > allocating, which Shaohua Li pointed out. Sadly, intel-iommu.c
> > converts DMA_64 to DMA_32 by def
On Wed, Apr 13, 2016 at 09:52:33PM +0300, Adam Morrison wrote:
> From: Omer Peleg
>
> IOVA allocation has two problems that impede high-throughput I/O.
> First, it can do a linear search over the allocated IOVA ranges.
> Second, the rbtree spinlock that serializes IOVA allocations becomes
> conte
On Wed, Apr 13, 2016 at 09:52:00PM +0300, Adam Morrison wrote:
> @@ -3738,7 +3743,16 @@ static void intel_unmap_sg(struct device *dev, struct
> scatterlist *sglist,
> int nelems, enum dma_data_direction dir,
> struct dma_attrs *attrs)
> {
> -
On Fri, Jan 22, 2016 at 01:14:56AM +0200, Adam Morrison wrote:
> On Wed, Jan 20, 2016 at 01:14:35PM -0800, Shaohua Li wrote:
>
> > > My understanding from the above is that the only issue with our
> > > patchset was not dealing with pfn_limit. I can just fix that and
&
On Wed, Jan 20, 2016 at 10:47:45PM +0200, Adam Morrison wrote:
> On Wed, Jan 20, 2016 at 8:10 PM, Shaohua Li wrote:
> > On Wed, Jan 20, 2016 at 01:21:03PM +0100, Joerg Roedel wrote:
> >> On Sun, Jan 10, 2016 at 07:37:59PM -0800, Shaohua Li wrote:
> >> > I don
On Wed, Jan 20, 2016 at 01:21:03PM +0100, Joerg Roedel wrote:
> On Sun, Jan 10, 2016 at 07:37:59PM -0800, Shaohua Li wrote:
> > I don't know you already posted one. Roughly looked at the patches. We
> > are using exactly the same idea. I'm happy we pursue your patches. A
On Mon, Jan 11, 2016 at 12:56:12AM +0200, Adam Morrison wrote:
> Hi,
>
> > iova alloc/free causes big lock contention, which could be easily
> > demonstrated
> > with iperf workload. Previously I posted a patchset:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.linuxfoundation.org_
iova free can be easily batched and remove the lock contention in unmap
path.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/intel-iommu.c | 17 -
drivers/iommu/iova.c| 27 +++
include/linux/iova.h| 1
unmap path does find_iova and follows __free_iova, which takes lock
twice. The find_iova isn't really required and so we can avoid the lock
overhead. Also next patch depends on this to reduce lock further.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/
e as the
previous one in the same test.
After this patchset, async_umap_flush_lock becomes the hotest lock in
intel-iommu, but not very bad. That will be something we need work on in the
future.
Thanks,
Shaohua
Shaohua Li (4):
IOMMU: add a percpu cache for iova allocation
iommu: free_iova doesn
cleanup the code a bit. free_iova doesn't need lock twice.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/iova.c | 62 +++-
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/iov
, 8k, 16k, 32k, 64k), each will cache 512K dma address. Each
cpu will cache 512k * 5 dma address at most. For an IOMMU system, the
cached dma address is quite tiny, so we don't bother draining cache for
CPU hotplug.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/
Ping!
On Tue, Nov 24, 2015 at 01:54:06PM -0800, Shaohua Li wrote:
> Hi,
>
> The lock contention in iova allocation is very significant. In my iperf test
> with intel 10Gbps NIC card with 48 threads, I observed 99% cpu time is
> spending
> on the lock contention. In
On Wed, Nov 25, 2015 at 10:38:00AM -0700, Jens Axboe wrote:
> On 11/25/2015 10:33 AM, Shaohua Li wrote:
> >On Wed, Nov 25, 2015 at 09:43:49AM -0700, Jens Axboe wrote:
> >>On 11/25/2015 09:40 AM, Woodhouse, David wrote:
> >>>On Wed, 2015-11-25 at 15:46 +0100, jroe.
On Wed, Nov 25, 2015 at 09:43:49AM -0700, Jens Axboe wrote:
> On 11/25/2015 09:40 AM, Woodhouse, David wrote:
> >On Wed, 2015-11-25 at 15:46 +0100, jroe...@suse.de wrote:
> >>On Tue, Nov 24, 2015 at 02:05:12PM -0800, Shaohua Li wrote:
> >>>The lib/iommu-common.c
On Tue, Nov 24, 2015 at 09:59:09PM +, Woodhouse, David wrote:
> On Tue, 2015-11-24 at 13:53 -0800, Shaohua Li wrote:
> > Currently if a device has rmrr or the device is a pci device,
> > passthrough is disabled even with iommu=pt. The worry is moving such
> > devices betwe
tion, user knows the risk. So intead of failing the
passthough, just print a warning and continue the passthough.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/intel-iommu.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/i
I can't test the bitmap allocation for dma-iommu, so just enable it for
intel iommu.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/intel-iommu.c | 6 +++---
drivers/iommu/iova.c| 4 ++--
include/linux/i
make alloc_iova return a pfn instead of iova. This is a preparation
patch.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/dma-iommu.c | 30 ++--
drivers/iommu/intel-iommu.c | 67 ++---
drivers/iommu
cleanup the code a bit. free_iova doesn't need lock twice.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/iova.c | 57
1 file changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/iov
On Tue, Nov 24, 2015 at 09:56:50PM +, Woodhouse, David wrote:
> On Tue, 2015-11-24 at 13:54 -0800, Shaohua Li wrote:
> >
> > This patch introduces a bitmap based allocator.
>
> Why not just use the one in lib/iommu-common.c? I'd like to see
> intel-iommu complete
comman case we
have highest request(DMA) per second. Bigger size DMA still fallback to rbtree
based allocation. But if required and DAC is enabled by default, it's easy to
support bigger size DMA in the bitmap allocation.
Thanks,
Shaohua
Shaohua Li (4):
iommu: alloc_iova returns a pfn
iommu
range and bigger chunk size.
Cc: Joerg Roedel
Cc: David Woodhouse
Signed-off-by: Shaohua Li
---
drivers/iommu/intel-iommu.c | 23 +++
drivers/iommu/iova.c| 93 +++--
include/linux/iova.h| 13 +++
3 files changed, 109 inser
26 matches
Mail list logo
