On Mon, Sep 15, 2008 at 11:44:57PM -0600, Matthew Wilcox wrote: > On Mon, Sep 15, 2008 at 11:13:20PM -0600, Grant Grundler wrote: > > And marking the BAR as prefetchable carries a fair amount of baggage. > > I don't know of any cards that implement prefetchable BARs. ie I expect > > it's not nearly as well tested. The only solution I know works is to add > > logic so the card can do DMA itself and thus burst longer streams of data > > to Host RAM. This is a non-trivial change though. > > Huh? > > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) > Subsystem: Fujitsu Limited. Device 13fe > Flags: bus master, fast devsel, latency 0, IRQ 16 > Memory at fc000000 (64-bit, non-prefetchable) [size=1M] > Memory at e0000000 (64-bit, prefetchable) [size=256M] > > I think every gfx card has a prefetchable BAR. Indeed...but does the CPU ever read from that memory space or only write to it? I was expecting only writes (to the device). I already pointed out most (older) gfx devices need to coalesce those writes for even decent performance. hth, grant > It's possible you might need to play around with the CPU page table > attributes to mark the mapping of the BAR as prefetchable in order > to get the CPU to request entire cachelines at once. You could try > ioremap_cache() in the first instance, but then might want to investigate > ioremap_prot() if thaqt doesn't work. > > -- > Matthew Wilcox Intel Open Source Technology Centre > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
