Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!garcon!bach.csg.uiuc.edu!conte
From: conte@bach.csg.uiuc.edu (Tom Conte)
Newsgroups: comp.arch
Subject: Re: i860 cache flushing
Message-ID: <665@garcon.cso.uiuc.edu>
Date: 27 Mar 89 23:00:26 GMT
References: <15888@winchester.mips.COM> <39485@oliveb.olivetti.com> <24958@amdcad.AMD.COM> <39722@oliveb.olivetti.com>
Sender: news@garcon.cso.uiuc.edu
Reply-To: conte@bach.csg.uiuc.edu.UUCP (Tom Conte)
Organization: Univ of Illinois at Urbana-Champaign
Lines: 21

About physical i-caches: it is not clear to me that a context switch
may not render lines in even physical i-caches invalid.  In a processor
where the i-fetch unit is what fills the i-cache, there is a chance
that after a context switch the OS will map a different page (of
instructions, perhaps) into a physical page frame that has some lines
in the i-cache.  The pager usually updates (or its data is run through)
the d-cache; hence, these updates won't get to the i-cache.

I see three ways around this: have the pager flush the i-cache
(selectively or always), use a hardware pid with the (*physical*)
i-cache, or somehow run paging of instruction pages through the i-cache.

Most of the arguments against always-flushing the i-cache are irrelevant
anyway since modern on-chip i-caches are too small to preserve any lines
of processes between context switches.

------
Tom Conte      Computer Systems Group, Coordinated Science Lab
               University of Illinois, Urbana-Champaign, Illinois
...The opinions expressed are my own, of course.
uucp:	 ...!uiucdcs!uicsrd!conte    internet:	conte@bach.csg.uiuc.edu