Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!julius.cs.uiuc.edu!rouellet From: rouellet@crhc.uiuc.edu (Roland G. Ouellette) Newsgroups: comp.arch Subject: Re: [m88200] cache flushes [on DG Aviion] Message-ID: Date: 17 Dec 90 21:54:59 GMT References: <1990Dec15.143354.8493@ux1.cso.uiuc.edu> <11421@pt.cs.cmu.edu> <1990Dec17.154858.2300@dg-rtp.dg.com> Sender: news@julius.cs.uiuc.edu (USENet News) Organization: University of Illinois Center for Reliable & High Performance Computing Lines: 24 In-Reply-To: hamilton@siberia.rtp.dg.com's message of 17 Dec 90 15:48:58 GMT > The reason for requiring OS assistance/interference (pick one, according > to your prejudices) in user cache operations is multi-processor systems. > Direct hardware support for cache invalidate and writeback commands in > an MP system is possible, but constrains and complicates the hardware > design immensely. Think about how hardware might implement cache > writeback/invalidate operations in an MP system.... Actually it's not all that bad. REI on VAX (besides doing a ton of other stuff) flushes the icache. A separate write-back instruction cache makes hardly any sense at all (expecially when you talk about using the OS to flush things back to memory... the instruction stream seldom changes... and the architecture can require the user, compiler, whatever, to do something when it does). The icache might take invalidates from other processors, but require a cache flush instruction upon dynamicly generating code. The hardware support is about six transistors per cache line in the instruction cache which is used to clear the valid bit on the line. In an MP system, having a large coherent shared backup will make the cache refill penalty reasonably small. -- = Roland G. Ouellette ouellette@tarkin.enet.dec.com = = 1203 E. Florida Ave rouellet@[dwarfs.]crhc.uiuc.edu = = Urbana, IL 61801 "You rescued me; I didn't want to be saved." = = - Cyndi Lauper =