Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site sjuvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!sjuvax!jss From: jss@sjuvax.UUCP (J. Shapiro) Newsgroups: net.arch Subject: Re: Help Requested on 80386 TLB Details Message-ID: <2619@sjuvax.UUCP> Date: Mon, 9-Dec-85 00:26:02 EST Article-I.D.: sjuvax.2619 Posted: Mon Dec 9 00:26:02 1985 Date-Received: Thu, 12-Dec-85 04:39:54 EST References: <1730@uw-beaver> Distribution: net Organization: Haverford College, Haverford, Pa. Lines: 106 I got a bit long winded on this, and I am sorry, but it seems to me that some readers of net.arch may be newcomers, and this may be helpful to them. Since I have a fair amount of the docs, let me try to answer some of these. % How is the TLB organized? Is it fully-associative, or direct mapped? The TLB is a "four-way set associative 32 entry page table cache" (p. 50, 80386 Data Book) I suspect it uses the 32 most recently used addresses. % Doesn't the TLB need to be flushed on a task switch? How is this flushing % specified? Are there any instructions for overtly managing the TLB? Yes, the TLB is process specific. It therefore will need to be flushed when tasks switch. While it is not stated anywhere that I can find, the TLB would seem to be flushed automatically as part of the execution of the CALL task instruction. % 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. On the first read from a page, the accessed bit of the page table entry gets set. on the first write to that page, the dirty bit gets set. Dirty and accessed bits are also kept in the TLB, so this is the only accessing necessary. In the translation tables. % When the OS clears the accessed bits for an address space, does it % update the TLB entries? No, the TLB entries for that address space have been flushed. They will be reestablished when the processor attempts to access the pages after returning to this process. % Can one fault on a page table? If not, how are these locked into memory? % How can the processor be sure that a page table directory is present? One can fault on a page table, so long as the page handling code and the page tables necessary to locate that code don't get swapped out. This is a general problem, and it is up to the pager to see to it that these things stay around. At the pager level, remember, you are looking in essence at physical memory, and it is therefore possible to see to it that the wrong things don't get swapped out by reserving locations for them and refusing to invalidate those page frames. Often enough, the pager will reserve different areas of memory for kernel paging and the rest of the world paging. This makes the maintainance easier. If the translation of segments is clear to you, the underlying page translation scheme is in essence identical to that used in the National chips, except that a few extra bits are available due to the 4k page size (instead of 512k on NatSemi's). These are made available to the user as "user defined bits". /*YOU MAY WANT TO "n" HERE - the remainder discusses virtual mem. fundamentals */ Forgive me if I am presumptuous, but it seems to me that your questions are most likely motivated by a lack of understanding of what happens in page faulting. The fault handler is not a part of the process in which the fault occurs. When a table lookup occurs, the running process won't be kicked out (except perhaps by something unrelated to paging), but will take a bit longer to fetch the translation. This translation is then added into the TLB, along with the accessed bits being set. Note that a read access automatically causes the accessed bits to be saet in both places. Access is implicit in the fact that you had to do the translation. If a write access occurs, the mmu (in this case) does another memory access to the page table entry to set the dirty bit. A fault occurs when it is discovered that the desired page isn't out there. In this event, the pager process is invoked, which probably queues up a disk request, sets your process to be nonrunnable, and sets the system back to multitasking. When the pager discovers that the disk request has come in, it finds a place for it, adds it into your process page tables, and sets your process state back to being runnable. The next time your number is up your process will be run beginning with the faulted instruction. Note that at least two process switches have occurred, and that the saving of your process's state causes the instruction to be retried as though (almost) nothing has happened. The translation lookaside buffer, however, has been completely invalidated, so it will be slowly reconstructed by your process. One could be careful, save the TLB entries, and have the pager be smart about invalidating them too, but in practice this takes as much if not more work as simply invalidating all of them, so it usually isn't done. For an adequate reference on paging, may I suggest chapters 5 and 6 of "Operating System Concepts" by Peterson and Silbershatz -- Jonathan S. Shapiro Haverford College "It doesn't compile pseudo code... What do you expect for fifty dollars?" - M. Tiemann