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"