From: David Woodhouse <dwmw2@infradead.org>
To: Dave Airlie <airlied@linux.ie>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
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:05:14 +0100 [thread overview]
Message-ID: <1246957514.2615.223.camel@macbook.infradead.org> (raw)
In-Reply-To: <alpine.DEB.2.00.0907062232350.5769@skynet.skynet.ie>
On Mon, 2009-07-06 at 22:35 +0100, Dave Airlie wrote:
>
> On Mon, 6 Jul 2009, David Woodhouse wrote:
>
> > On Mon, 2009-07-06 at 15:11 +0200, Joerg Roedel wrote:
> > > Ok, cool, that sounds good. Which in-kernel DRM drivers break with IOMMU
> > > for you? I'll may probably add a similar temporary workaround for AMD
> > > IOMMU too...
> >
> > The Intel one definitely broke -- I don't know about the others. There
> > are some old patches at http://people.freedesktop.org/~zhen/agp-mm-*
> > which make it look like _all_ AGP drivers are broken.
> >
> > I wouldn't bother adding the workaround -- as I said, I'm planning to
> > rip it out of 2.6.32 (and in linux-next as soon as it's reasonable to do
> > so). Let's just let them fix it.
>
> cc'ing Eric,
>
> 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.
If the IOMMU is absent, disabled or in pass-through mode, then the
performance impact should be virtually zero.
It's the case where the IOMMU is in use that matters -- and the choice
there is between "slow" and "broken". I'll take "slow", please.
Having said that, I've done a bunch of performance work recently and
especially multi-page mappings are a _lot_ faster than they used to be.
I'll see if I can do more once I can test it with your actual usage
patterns.
We currently have an evil hack which uses a shitload of memory to set up
a full set of page tables to map all of physical memory, for every
graphics device at boot time whether we need it or not. The AMD folks
have so far resisted doing that, partly because of the amount of RAM it
would take. I'm getting poked from all sides to _remove_ our hack.
> 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.
Anything with Cantiga chipset would suffice. Lenovo x200s, T400, etc...
> Could you also enumerate any limitations of the IOMMUs on the amount
> of memory they can remap per device if any.
The Intel one basically has no relevant limit -- it's 54 bits of virtual
address space or something like that.
I think I saw something about the AMD one perhaps being limited to 4GiB
per device -- which makes 1:1 mapping of all memory a lot less feasible,
but I'll let Jörg answer that question definitively.
Not sure about other platforms off-hand.
--
dwmw2
next prev parent reply other threads:[~2009-07-07 9:05 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
2009-07-07 9:05 ` David Woodhouse [this message]
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=1246957514.2615.223.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