Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!usc!apple!sun-barr!newstop!sun!skylark!katin
From: katin@skylark.Sun.COM (Neil Katin)
Newsgroups: comp.arch
Subject: Re: SRAM vs. DRAM, 33MHz 386 UNIX-PC
Message-ID: <124529@sun.Eng.Sun.COM>
Date: 12 Sep 89 18:42:15 GMT
References: <21936@cup.portal.com> <7851@cbmvax.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: katin@sun.UUCP (Neil Katin)
Organization: Amorphous Systems, Los Gatos, CA
Lines: 27

In article <7851@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
=in article <21936@cup.portal.com>, cliffhanger@cup.portal.com (Cliff C Heyer) says:
=> 1. UNIX (or any multitasking OS) and the effects of 
=> the on-board cache:
=
=>  	While multitasking, does flushing the cash waste a measurable amount 
=> of run time or is it insignificant compared to swapping, paging, and/or 
=> other overhead? 
=
=Generally, UNIX system do cache flushes when they enter kernel space, and they
=MUST between user tasks, since the address spaces are aliased.  Caching still
=helps under UNIX, maybe even considerably depending on the main memory design,
=but you won't get the maximum possible performance out of a system under UNIX.

There is no need to flush the cache on task switches on the 80386 (the
subject of the original question) because the cache is a physical cache
-- there is no address aliasing in the cache because the cache works
with physical addresses (i.e. addresses that have already been
translated by the MMU.  This is one of the big advantages of caching
based in physical rather than virtual addresses.

You *do* need to flush the on-chip 68030 cache when doing task switches
because it is a virtual cache.  You probably don't need to flush any
off-chip 68030 caches because they are physical caches (since the 68030
has an on-chip MMU).

Neil Katin