Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!rtech!mtxinu!taniwha!paul
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch
Subject: Re: 88K table walk
Message-ID: <235@taniwha.UUCP>
Date: 7 Dec 88 17:03:43 GMT
References: <3798@pt.cs.cmu.edu>
Reply-To: paul@taniwha.UUCP (Paul Campbell)
Organization: Taniwha Systems Design, Oakland
Lines: 27

In article <3798@pt.cs.cmu.edu> dpm@k.gp.cs.cmu.edu (David Maynard) writes:
>The OS will actually be working with the tables as data.  I assume that data
>accesses would load the table entries into the D-cache.  There might be a
>case (page faults maybe) where already having a particular table entry
>already cached from a walk might speed up an OS function.  I'll have to

Of course on a system where TLB miss is in software then page tables are
simply a figment of the OS's imagination ... the hardware doesn't care
or know if they are out there (in this case design becomes a compromise
between how easy your PTEs can be bent into the format to be poked in the
chip's TLB entries vs a design that maps what you OS needs [for example BSD
has different requirements from SV]).

On the other hand one of the most expensive part of an operating system's
manipulation of page tables is the need to flush the TLB when changes are
made to the tables (ie to the mappings which they represent) ... the more
you cache (segment table entries for example) the more the code has to be
aware of the hardware .... I guess this is an argument for putting them
in the data cache.

		Paul

-- 
Paul Campbell			..!{unisoft|mtxinu}!taniwha!paul (415)420-8179
Taniwha Systems Design, Oakland CA

 	"Read my lips .... no GNU taxes"