Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!sun!idi!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.arch
Subject: Re: Re: Help Requested on 80386 TLB Details
Message-ID: <157@intelca.UUCP>
Date: Mon, 16-Dec-85 21:03:25 EST
Article-I.D.: intelca.157
Posted: Mon Dec 16 21:03:25 1985
Date-Received: Wed, 18-Dec-85 05:05:34 EST
References: <1730@uw-beaver> <2619@sjuvax.UUCP> <867@x.UUCP>
Distribution: net
Organization: Intel, Santa Clara, Ca.
Lines: 42

> 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

Any time you write to CR3, the page table TLB is invalidated.  Thus, you
needn't switch the entire context of the processor to invalidate the
TLB.  As part of the context switch, CR3 gets reloaded, but there is also an
instruction that only loads CR3.  Also, one would hope that the operation
in which the page tables are examined to toss out a couple here and there
to virtual memory happens pretty infrequently, otherwise you spend quite
a bit of time just making this determination.  Relatively, the amount
of time for all the processors in your system to respond to an interrupt
that forces them to reload their respective CR3s is pretty insignificant.
-- 
remember, if you do it yourself, sooner or later you'll need a bigger hammer

Ken Shoemaker, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.