linux-mips-fnet
[Top] [All Lists]

Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)

To: linux-mips@fnet.fr
Subject: Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)
From: "Gleb O. Rajko" <rajko@mech.math.msu.su>
Date: Fri, 21 Aug 1998 14:00:23 +0400 (MSD)
In-reply-to: <199808210832.JAA00304@gladsmuir.algor.co.uk>
On Fri, 21 Aug 1998, Dominic Sweetman wrote:

> > > What we still can't understand is when we must flush
> > > I-cache. Well, we do understand it in theory - I-cache must be
> > > flushed when new mapping for a physical page occurs.
> 
> There are two operations you can need to do on a cache line.  You can
> *invalidate* it (so any further access to it will re-fetch it from
> memory?); you can do a *writeback* - write it back to memory, if
> there's any data the CPU written but which has so far only got stored
> in the cache.

In terms of I-cache writeback is a very interesting operation :-)
> 
> The word "flush" is widely used to mean invalidate, and widely used to
> mean invalidate and writeback, and probably sometimes used to mean
> just writeback.  So I'd recommend you don't use that word at all...
> 

We discuss r3k so word "flush" means just invalidate. 

> > o Copying code. In this case the D-cache would be up to date, but
> > the I-cache doesn't know that code has changed. Here the I-cache has
> > to be flushed.
> 
> You need to do a D-cache writeback, followed by an I-cache invalidate,
> of any cache lines containing the code area you've copied to.
> 
> BUT you don't normally need to do anything to MIPS caches when you
> change page mappings.

Consider the following scenario. A region (physical page) is swapped (on a 
backing store), immediately filled by new data, new virtual page is 
mapped to this region. There is a non-zero probability that old data 
still lives in I-cache...  

Regards,
Gleb.

<Prev in Thread] Current Thread [Next in Thread>