Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@bach.crhc.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Paging page tables Message-ID: Date: 30 Jun 90 01:45:50 GMT References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> Sender: usenet@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 50 In-Reply-To: lindsay@MATHOM.GANDALF.CS.CMU.EDU's message of 28 Jun 90 20:23:51 GMT >The chip designer does control the cost of a simple TLB refill. For >example, the 88000 and 68020 (well, 68851) have table-walk hardware, >whereas the R3000 designers punted TLB refill to an interrupt handler >and some special instructions. I hope that "punted" isn't derogatory. First off, the hardware complexity/performance tradeoffs involved in the MIPS software TLB miss handling decision were described in a paper somewhere, and seemed reasonable. It could go either way. Second, though, from the point of view of someone who aspires to architect HW/OS/SW systems (note that OS is somewhere in the middle :-) ), SW TLB handling is wonderful for experimentation at least. For example, you can do a lot of MACH style remapping to avoid copying, by letting the user modify some parts of the translation tables (which therefore get spread over several pages) and making the TLB miss handler enfore security. Eg. let the user specify that a PTE points to another virtual address (not physical - that leads to security problems). And so on. Of course, you can always do this via system calls, but by careful design you can reduce the number of TLB flushes required (which might be the only thing you want a syscall for) by 1/2. More, if you are going to use this for things like LISP style garbage collection. Similarly, many applications (from security minded Europeans, in my experience) wish to restrict the ability to access certain areas of memory. Eg. you have a database that you want to be readable/writable only from the database code. You can always use a system call to change the perms, but, as several customers I was called in to found out, that's slow. By putting some of the perms in a user-modifiable part of memory, and changing the fault handler, you can always *relax* the perms (go from non-accessible to accessible) without a system call. Going back requires a TLB flush, which you might have to use a syscall for - but still, 1 syscall as opposed to 2 is pretty good. Of course if the TLB miss handling is comparable to a syscall in slowness you haven't gained much - but isn't MIPS' point that the SW TLB miss handler is *not* as slow as a syscall? NB. I do not propose that the TLB miss handler be purely user code. Just that it interact with some (untrusted) user accessible data structures. In addition to user interaction with the virtual address mapping, SW TLB handling also gives you the flexibility to use new data structures for the virtual-to-physical mapping. For example, with potentially *very* large address spaces impending, extent based mapping structures may be necessary to save space. -- Andy Glew, aglew@uiuc.edu