Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site x.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!harvard!think!mit-eddie!cybvax0!frog!x!rfm
From: rfm@x.UUCP (Bob Mabee)
Newsgroups: net.arch
Subject: Re: Help Requested on 80386 TLB Details
Message-ID: <867@x.UUCP>
Date: Thu, 12-Dec-85 23:54:33 EST
Article-I.D.: x.867
Posted: Thu Dec 12 23:54:33 1985
Date-Received: Sun, 15-Dec-85 06:38:23 EST
References: <1730@uw-beaver> <2619@sjuvax.UUCP>
Reply-To: rfm@x.UUCP (Bob Mabee)
Distribution: net
Organization: Charles River Data Systems, Framingham MA
Lines: 25

In article <2619@sjuvax.UUCP> jss@sjuvax.UUCP (J. Shapiro) writes,
in response to rose@uw-beaver (Scott Rose):
>% On a page fault, how is the TLB entry, if any, updated for the replaced
>% page?  The present bit must be cleared, and the dirty bit must be read.
>
>I think you may not have this right.  For a page to be in the TLB, it
>must have been there at one point.  The question is whether or not the
>invalidation of a page frame will cause appropriate invalidation in
>the TLB.  The answer is yes, as the page is not given up voluntarily
>by that process.  Some other process goes and invalidates the page,
>and the consequent TLB flush will cause the TLB to be properly
>maintained.

That isn't good enough.  Reasonable systems may require invalidating a page
within one process, rather than whenever a page-scrounging daemon runs.
Consider exec, or suppose that sbrk is actually implemented to give back
memory.  Also, if you have multiple processors there is not necessarily a
process exchange on this CPU every time the scrounger takes away a page.

If Intel has not provided a clear-TLB command, then the OS will have to use
the magic context-switch instruction even when only the TLB side effect is
wanted.  By the way, a clear-TLB pin would expedite multi-processor systems.
-- 
				Bob Mabee @ Charles River Data Systems
				decvax!frog!rfm