Can a TLB hit lead to page fault in memory?

Question

In UC Berkley Video lectures on OS by John Kubiatowicz (Prof. Kuby) available on web, he mentioned that TLB hit doesn't mean that corresponding page is in main memory. Page fault can still occur.
Technically TLBs are cache for page table entry and since all page table entries don't have their corresponding page available in main memory. Same can be true for TLBs. A TLB hit may lead to page fault.

But according to algorithms given in text books I am unable to find such a case. On a TLB miss kernel refer to page tables and update the TLB cache for appropriate address translation. Next TLB hit can't lead to page fault. When kernel swap out the page, it updates the appropriate bits for that page table entry and invalidate the corresponding TLB, so there can't be a TLB hit next time until page is loaded in main memory.

So can someone stand for correctness of Prof kuby's claim and point out a case when instead of TLB hit (the translated physical address for corresponding virtual address in found in TLB), a page fault can occur?

Laciniate

Andy Glew's CompArch wiki has a page on caching invalid entries in a TLB which might be of interest. – Toritorie

Since the CompArch wiki is currently not working, I have posted a copy of the CompArch wiki entry Caching Invalid Entries. (I have also posted some others.) – Toritorie

Answer 1

One example is if the memory access is different from the allowed one.

e.g. you want to write to memory that's write protected. A TLB exists, it's a hit and the address is translated. But on access you get a trap, as you're trying to write to memory that's read-only

Forsythe

+1 another similar example would be a private mapping, hitting a copy-on-write page for the first time. This will not only generate a trap, but will also cause the kernel to create a totally new page. The page could be in the TLB if you had only been reading from it previously. It's interesting what the kernel would do in that case, though... keep both TLB entries, or just the new one, or ...? I guess it's probably the latter since TLB is rather short-lived, but I wouldn't know for sure. – Infallible

Though your answer gives some new perspective to think but still trap is not a page fault. The kernel will deny access rather than reloading that page in memory. – Laciniate

@Damon: Two process can have same virtual address for different pages-frames in memory.Kernel must have some tags for it ( I don't know the actual mechanism) but still kernel differentiate between 2 same virtual address of 2 different process. I think same case apply to copy-on-write page which is the case for fork() system call. After making the new copy of page, though the two pages have same virtual address, kernel can still keep both entries because they belong to different processes after fork. – Laciniate

After going through rwong's link, I take my above comment back. Your answer is genuine. – Laciniate

RWong deleted his answer, which linked to these lecture notes. Reposting for future readers without enough rep to see deleted answers. – Playtime

Answer 2

A page fault doesnt mean a missing page in the memory. A page can still be present and be dirty. This is also a page fault. On a general note, the page fault refers to the scenario where the obtained translation cannot be effectively used. It may be a missing page or a dirty page or access permission mismatch. So a TLB hit can still lead to a page fault.

Warfield

Why would a dirty page lead to a page fault? – Cannonry

A write to a clean page might trigger a page fault for copy-on-write, if the hardware page tables had it mapped read-only. A read or write to an already-dirty page don't need to update any state, not even the "dirty" or "accessed" bits in the PTE (which hardware normally takes care of updating, at least on x86, not via a page fault.) – Playtime

Answer 3

patterson says:"cannot have a translation in TLB if page is not present in memory" [computer organization and design,4th ed revised, page 507]

Saturable

Note that TLB has two meanings: (1) As a general logic component in all memory-based cache systems, (2) Specifically as an architectural component in the virtual address to physical address translation step. Your statement above only applies to (1), which is that a memory access that has failed could not have resulted in anything being added to the cache. However, when TLB refers to the MMU (memory management unit) which is under full control of OS, the translation table is completely specified by the OS, including entries that indicate "issue software trap if this virtual address is hit". – Mendiola

Or else, your quoted statement simply don't correspond to the modern CPU architecture anymore. – Mendiola

There is a third possibility: a cache system designed to cache the frequently-used entries from the MMU translation table. In this case, your quoted author is right (as a matter of opinion) in saying that there is little point in caching an entry that maps to an illegal access, but in modern CPUs and OSes, the use of virtual paging system (pretending to have larger virtual memory space than the physical memory space) is so rampant that it makes perfect sense to cache these entries as well, because you will certainly hit them a lot of times. – Mendiola

This is true I think, but not-present isn't the only reason a page fault can happen. (I could imagine a TLB doing negative-caching if software-prefetch or other fault-suppressing mechanisms are commonly used by real code. The ISA rules on x86 for when TLB entries need to be invalidated don't include when changing from not-present to present, though, so any caching of not-present has to be transparent / coherent with stores to PTEs.) – Playtime