[LinuxBIOS] Opteron caching of device memory

Myles Watson myles at pel.cs.byu.edu
Thu Jun 14 22:39:14 CEST 2007


> Myles Watson wrote:
> >> On 6/13/07, Myles Watson <myles at pel.cs.byu.edu> wrote:
> >>
> >>> I'm using LinuxBIOS on my Tyan s2892.  I have a device that maps a lot
> >>> of the memory space, but I'm struggling trying to get the Opteron to
> >>> read and write to my device in larger blocks.  I have set the variable
> >>> MTRRs in the device driver to writeback (witnessed by /proc/mtrr), but
> I
> >>>
> >
> >
> >>> still get 64-bit accesses instead of 64-byte (cache line).
> >>>
> >> wirte-back or write-combining?
> >>
> >> YH


> > I did write-back, because I would like it to be treated as much like
> > DRAM as possible.
> >
> > Myles
> >
> Hi Myles,
> I am not an Opteron expert but here are a few items you might want to
> check.
> 
> I assume that this is a PCI/E/X device. Is the device memory BAR and
> bridge memory set as prefetchable?


 It is HyperTransport, but pretty much the same. I set it as prefetchable.
The reads actually work, it's the writes that come through 8-bytes at a
time. 

> Check that you don't have any overlapping mtrrs. I think that they
> resolve to the most restrictive setting
> Check the PAT setting for that memory. The memory page will resolve to
> the most restrictive setting. (Note I am not sure if Linux uses PAT)
> See section 7.6 of the System Programmers Guide Volume 2. You can get
> here:
>
http://www.amd.com/gb-uk/Processors/TechnicalResources/0,,30_182_739_7044,00
.html


I'll look.

> You might get some performance by caching the device memory space but I
> don't  think that it is the best use of the cache. If you are moving a
> lot memory between your device and system memory it is best that the
> driver DMA it in instead of reading it in with the CPU.

I'm using the device to explore paging activity, so I'm not after speed as
much as I am trying to make the device seem as much like RAM as possible

Thanks for your help,
Myles






More information about the coreboot mailing list