how is virtual address translated to its physical address on backing store?

Question

We have address translation table to translate virtual address (VA) of a process to its corresponding physical address in RAM, but if the table does not have any entry for a VA , it results in page fault and kernal goes to backing store (often a hard drive) and fetch the corresponding data and update the RAM and address translation table. So my question is how does the OS come to know what is the address corresponding to a VA in backing store ? Does it have a separate translation table for that?

Answer 1

I think your question answer is issue about interrupt table. Page fault is a kind of software interrupt, and operating system must have some solution to that interrupt.And the solution code is already in the os kernel, and that piece of code address is right at the interrupt table.So the page fault happen, os will go to that piece of code to get the unmapped page into the physical memory.

Answer 2

A process starts by allocating virtual memory. That eventually will cause a page fault when the program starts actually addressing the virtual memory address. The OS knows that the memory access is valid. Since it was allocated explicitly.

So no harm done, the OS simply maps the VM address to a physical address.

If the page fault is for an address that was not previously requested to be a valid VM address then the processor will discover that there is no page table entry for the address. And will instead raise an GP fault, an AccessViolation or segfault in your program. Kaboom, program over.

Answer 3

There is no direct correlation, at least not in the way that you suppose.

The operating system divides virtual and phsyical RAM as well as swap space (backing store) and mapped files into pages, most commonly 4096 bytes.

When your code accesses a certain address, this is always a virtual address within a page that is either valid-in-core, valid-not-accessed, valid-out-of-core, or invalid. The OS may have other properties (such as "has been written to") in its books, but they're irrelevant for us here.

If the page is in-core, then it has a physical address, otherwise it does not. When swapped out and in again, the same identical page could in theory very well land in a different physical region of memory. Similarly, the page after some other page in memory (virtual or physical) could be before that page in the swap file or in a memory-mapped file. There's no guarantee for that.

Thus, there is no such thing as translating a virtual address to a physical address in backing store. There is only a translation from a virtual address to a page which may temporarily have a physical address. In the easiest case, "translating" means dividing by 4096, but of course other schemes are possible.

Further, every time your code accesses a memory location, the virtual address must be translated to a physical one. There exists dedicated logic inside a CPU to do this translation fully automatically (for a very small subset of "hot" pages, often as few as 64), or in a hardware-assisted way, which usually involves a lookup in a more or less complicated hierarchical structure.
This is also a fault, but it's one that you don't see. The only faults that you get to see are the ones when the OS doesn't have a valid page (or can't supply it for some reason), and thus can't assign a physical address to the to-be-translated virtual one.

When your program asks for memory, the OS remembers that certain pages are valid, but they do not exist yet because you have never accessed them.

The first time you access a page, a fault happens and obviously its address is nowhere in the translation tables (how could it be, it doesn't exist!). Thus the OS looks into its books and (assuming the page is valid) it either loads the page from disk or assigns the address of a zero page otherwise.

Not rarely, the OS will cheat and all zero pages are the same write-protected zero page until you actually write to it (at which point, a fault occurs and you are secretly redirected to a different physical memory area, one which you can write to, too.

Otherwise, that is if you haven't reserved memory, the OS sends a signal (or an equivalent, Windows calls it "exception") which will terminate your process unless handled.

For a multitude of reasons, the OS may later decide to remove one or several pages from your working set. This normally does not immediately remove them, but maked them candidates for being swapped (for non-mapped data) or discarded (for mapped data) in case more memory is needed. When you access an address in one of these pages again, it is either re-added to your working set (likely pushing another one out) or reloaded from disk.

In either case, all the OS needs to know is how to translate your virtual address to a page identifier of some sort (e.g. "page frame number"), and whether the page is resident (and at what address).

Answer 4

This is OS-specific, but many implementations share logic with memory-mapped file features (so that anonymous pages actually are memory-mapped views of the pagefile, flagged so that the content can be discards at unmapping instead of flushed).

For Windows, much of this is documented here, on the CreateFileMapping page