Re: [Gems-users] Flush back L2 Cache

["Min Xu (Hsu)" <xu@xxxxxxxxxxx>]

Milo,

I agree with you. The FDR implementation did have a virtual
processor that issues DMA requests obtained from simics.

On the other hand, keeping DMA requests coherent is just one
option, isn't it? One can imagine OS needs to flush caches
and DMA transfer happens directly between memory and devices,
i.e. not cache coherently.

-Min

On Thu, 10 Feb 2005 Milo Martin wrote :
> On Feb 10, 2005, at 3:32 PM, Weihang Jiang wrote:
> 
> >What I am asking is about memory replacement. When a physical memory
> >page is replaced, the corresponding L2 cache lines need to be flushed
> >first.
> 
> I'm not sure I understand what you're saying.  When a physical memory 
> page is replaced, the TLB entry needs to change, but the blocks in the 
> cache can stay where they are.  When the operating system actually 
> swaps in the new page, the DMA controller will need to write the 
> various blocks in the page.  These DMA writes are responsible for 
> invalidating (or updating) any caches that might have readable copies 
> of the block.  Currently, Ruby doesn't treat DMA writes in this way, 
> but at one point we had a version that treated all DMA operations as 
> happening on either a separate virtual processor or as all DMA 
> happening at processor zero.  Simics gives us all of these requests, we 
> currently just choose to ignore them.
> 
> Does that make sense, or am I misinterpreting the question?
> 
> - Milo
> 
> --
> Milo M. K. Martin (milom@xxxxxxxxxxxxx)
> http://www.cis.upenn.edu/~milom/
> Assistant Professor
> Computer and Information Sciences Department
> University of Pennsylvania
> 
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users