Path: utzoo!attcan!uunet!cs.utexas.edu!asuvax!mcdphx!phx.mcd.mot.com!df
From: df@phx.mcd.mot.com (Dale Farnsworth)
Newsgroups: comp.sys.m88k
Subject: Re: m88200 cache flushes on DG Aviion
Message-ID: <14251@mcdphx.phx.mcd.mot.com>
Date: 13 Dec 90 15:25:32 GMT
References: <2308@io.UUCP> <1199@dg.dg.com> <4322@photon.oakhill.UUCP> <9704@orca.wv.tek.com>
Sender: listen@mcdphx.phx.mcd.mot.com
Reply-To: df@phx.mcd.mot.com (Dale Farnsworth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 32

> 	"Using memctl() is the only way to insure that the code will
> 	be portable at all ... In fact it may even be fairly efficient
> 	since the 88200 can flush or invalidate a line at a time."
> 
> In the Motorola kernel, the memctl implementation is moby inefficient.
> It has to be, because there's no memctl option that says "just flush
> cache"; instead, the code must run through segment and page descriptors
> flipping the writable state.
> 
> This was enough of a problem that Tektronix implemented a "just flush
> the cache" system call in our kernel, for a customer who did
> incremental compilation and didn't need to be BCS compliant.

Just to clear up some misinformation ...

The above quote must refer to another vendor.  There is nothing in the BCS
specification of memctl which requires flipping the writable state of page
descriptors and no Motorola kernel has ever done so.

Normally, our implementation of memctl validates arguments, sets a couple of
flags and flushes the caches.  There is a single exception to this: the
first (and only the first) time a shared text region is made modifiable by
memctl, it is changed into a copy-on-write region which incurs additional
overhead.

I can think of no reason that a memctl implementation needs to have
significantly more overhead than a system call to flush the caches.

-Dale

-- 
Dale Farnsworth		Motorola Computer Group