All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@cup.hp.com>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-mm@kvack.org
Subject: Re: IOMMU setup vs DAC (PCI)
Date: Fri, 09 Feb 2001 12:04:00 -0800	[thread overview]
Message-ID: <200102092004.MAA08263@milano.cup.hp.com> (raw)
In-Reply-To: Your message of "Fri, 09 Feb 2001 11:42:56 PST." <14980.18496.329382.393791@pizda.ninka.net>

"David S. Miller" wrote:
> You are going into unchartered territory.  IA64 supports 64-bit
> DMA as a HACK at best (see qla20xx driver) and uses a software
> iommu implementation to handle all normal drivers using the
> supported 32-bit pci_*() interfaces.

Ah ok. that's what I was afraid of.

> The 64-bit support API will appear in 2.5.x, no sooner.
> 
> And all that talk of IOMMU overhead assumes a shit implementation of
> TLB flushing.

Yup. That's us. :^(
For "SBA" IOMMU, CPU has to invalidate TLB entries since the board
designers *botched* the implementation. TLB and IOPdir were *supposed*
to be coherent.

Future implementations are promised to work correctly.
I'll believe it when I see it.

> With a sane setup you only flush once per circle walk
> of the page tables, see the tricks in sparc64/kernel/pci_iommu.c to
> see what I'm talking about.  I can push 2 gigabytes to a disk over
> SCSI and only take 18 PIOs to the IOMMU.

I've been able to reduce PIO *read* overhead a bunch.
Normally every PIO write to TLB invalidate has to be followed by a read
to guarantee the IOMMU sees the write.  I bundle several (32 or more)
PIO writes together and follow with one read. The read overhead
disappears in mix with other overhead. So while it sucks, it's not
*really* bad...

> Also, many IOMMU based PCI
> implementations do not offer the software managed
> prefetching/write-behind facilities when 64-bit DAC is used.
>
> I say stay at 32-bit IOMMU based stuff for now.

ok - tnx!

grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2001-02-09 20:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-09 19:39 IOMMU setup vs DAC (PCI) Grant Grundler
2001-02-09 19:42 ` David S. Miller
2001-02-09 20:04   ` Grant Grundler [this message]
2001-02-09 19:47 ` Kanoj Sarcar
2001-02-09 19:52   ` David S. Miller
2001-02-09 20:07     ` Kanoj Sarcar
2001-02-09 20:23       ` David S. Miller
2001-02-09 21:11         ` Kanoj Sarcar

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=200102092004.MAA08263@milano.cup.hp.com \
    --to=grundler@cup.hp.com \
    --cc=davem@redhat.com \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.