mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: Dave Airlie <airlied@linux.ie>, Joerg Roedel <joro@8bytes.org>,
	Zhenyu Wang <zhenyu.z.wang@intel.com>,
	linux-kernel@vger.kernel.org, fujita.tomonori@lab.ntt.co.jp,
	iommu@lists.linux-foundation.org, mingo@redhat.com,
	David Miller <davem@davemloft.net>,
	eric@anholt.net
Subject: Re: IOMMU and graphics cards
Date: Tue, 07 Jul 2009 10:16:31 +0100	[thread overview]
Message-ID: <1246958191.2615.234.camel@macbook.infradead.org> (raw)
In-Reply-To: <20090707085904.GP5380@amd.com>

On Tue, 2009-07-07 at 10:59 +0200, Joerg Roedel wrote:
> On Mon, Jul 06, 2009 at 10:35:59PM +0100, Dave Airlie wrote:
> > My memory of this is graphics becomes totally useless and can be 10x-50x 
> > slower. I think ripping this out without the person doing the ripping 
> > taking responsiblity for doing speed regression testing is totally insane.
> 
> Are you sure that using the dma-api has such an performance impact? I've
> heard from other people that switching to dma-api with amd iommu had no
> significant performance impact.

The DMA API on its own shouldn't hurt at all. and I'm not sure about the
AMD IOMMU.

It's the other IOMMU that hurts -- something about cache-incoherent page
tables and having to flush the cache for every change... especially on
an architecture which doesn't have any sane cache management (because it
was always designed for everything to be cache coherent, dammit!) so you
end up _invalidating_ the cache at the same time as you write it back!

Of course, it's a lot saner now that we don't individually flush the
cache after _every_ PTE we change, but do it in batches instead.
Multi-page mapping/unmapping is now a _lot_ faster than it used to be.

I'm also looking at mapping the page tables uncached, so we don't have
to do the cache flushes at all.

> > I personally have no IOMMU hw from Intel or AMD and nobody has seen it fit 
> > to supply me with any at any point in time, I'm not on the correct gravy 
> > train. So I suspect the people with the hw will have to do the work and 
> > the regression testing.
> 
> You just need to switch to dma-api. You don't need an iommu to test.
> Most bugs in such code can also be found and eliminated using the
> dma-api debugging interface.

Indeed. Just turn on CONFIG_DMA_API_DEBUG (that might have some
performance impact, but it's not huge).

-- 
dwmw2


  reply	other threads:[~2009-07-07  9:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-28 15:05 Joerg Roedel
2009-04-28 15:28 ` David Woodhouse
2009-04-28 16:04   ` Joerg Roedel
2009-05-07  7:47     ` FUJITA Tomonori
2009-05-07 10:01       ` Joerg Roedel
2009-05-07 10:22         ` David Woodhouse
2009-05-07 10:42           ` FUJITA Tomonori
2009-05-07 12:15           ` Joerg Roedel
2009-05-07 12:59             ` FUJITA Tomonori
2009-05-07 14:37               ` Joerg Roedel
2009-05-07 17:04             ` Christoph Hellwig
2009-05-07 18:36           ` David Miller
2009-05-08  9:35             ` Joerg Roedel
2009-07-06 12:26               ` David Woodhouse
2009-07-06 13:11                 ` Joerg Roedel
2009-07-06 14:18                   ` David Woodhouse
2009-07-06 21:35                     ` Dave Airlie
2009-07-06 22:00                       ` Dave Airlie
2009-07-07  8:54                         ` Joerg Roedel
2009-07-07 15:24                         ` Duran, Leo
2009-07-07 15:33                           ` Duran, Leo
2009-07-07 15:36                             ` David Woodhouse
2009-07-07  8:59                       ` Joerg Roedel
2009-07-07  9:16                         ` David Woodhouse [this message]
2009-07-07  9:05                       ` David Woodhouse
2009-05-07 10:23         ` FUJITA Tomonori
2009-05-07 11:01           ` Ingo Molnar
2009-05-07 11:14             ` FUJITA Tomonori
2009-05-07 11:26               ` Ingo Molnar
2009-05-07 12:00           ` Joerg Roedel
2009-05-07 10:55         ` Ingo Molnar

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=1246958191.2615.234.camel@macbook.infradead.org \
    --to=dwmw2@infradead.org \
    --cc=airlied@linux.ie \
    --cc=davem@davemloft.net \
    --cc=eric@anholt.net \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=zhenyu.z.wang@intel.com \
    /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

Powered by JetHome