I am a novice in an operating system and curious about the page fault.
I am reading Operating System Concetp(10th) and it say:
A handling page fault follow these sequence
1. Trap to the operating system
2. Save the user registers and process state
3. Determine that the interrupt was a page fault
4. Check that the page reference was legal and determine the location of the page on the disk
5. Issue a read from the disk to a free frame:
a. Wait in a queue for this device until the read request is serviced
b. Wait for the device seek and/or latency time
c. Begin the transfer of the page to a free frame
6. While waiting, allocate the CPU to some other user
7. Receive an interrupt from the disk I/O subsystem (I/O completed)
8. Save the registers and process state for the other user
9. Determine that the interrupt was from the disk
10. Correct the page table and other tables to show that the page is now in memory
11. Wait for the CPU to be allocated to this process again
12. Restore the user registers, process state, and new page table, and then resume the interrupted instruction
I cannot imagine other tables in step 10 other than the page table.
Can you give me some examples?
Modern CPUs expect several page tables. For x86-64, the MMU (memory management unit) in the CPU takes the address stored in the CR3 register (stored there at boot by the OS). This address is the address of the first table (PML4). The PML4 table contains addresses of the second table and so on. The virtual address is split into 5 parts. The first 4 parts are the offsets in respective tables and the last part (12 bits) is the offset in the page in main memory. Today, only 48 bits of the 64 bits virtual addresses are used.
When you use virtual addressing the CPU will translate the virtual address using the MMU before putting the address on the address bus. It will basically cross each table taking one part of the virtual address at a time until it reaches the last table which is present in memory.
When a page fault occurs, a certain interrupt line is raised by the CPU. The interrupt number (of a page fault) is linked to a certain handler in the IDT by the OS at boot. The address of the IDT in RAM is stored in the LIDT register. The handler will do the steps mentioned in your example. It will correct all page tables and return.
Related
Didn't able to understand where is virtual address space is present is it in RAM or HARD-DISK?
If it is present in RAM then How it's address space is larger than physical address space?
Virtual addresses,as their name implies, are virtual. Their are only manipulated by the processor and do not correspond to actual addresses until they are translated.
Translation is done by the hardware, thanks to tables that are filled by the operating system. These tables indicates for every potential virtual page address to which physical page address it corresponds. So mostly, virtual addresses are mapped to physical (RAM) addresses.
Didn't able to understand where is virtual address space is present is it in RAM or HARD-DISK? If it is present in RAM then How it's address space is larger than physical address space?
A process always has the same kind of memory structure in terms of virtual addresses. At the lower address end, there are the instructions, global data, and the heap, that are organized in several sections. At the upper end, are the program parameters (argv) and the stack. In between there is free space that allows the stack and the heap to grow.
So there are addresse equal to 0 (the first instruction of a program) and to 0xfffffffffffffffff (start of the stack).
Obviously is is far beyond the capacity of most (all?) present RAM. With 64 bits virtual addresses and a 4GB RAM (32 bits), at most one page over 1 billion can be used.
But the mapping mecanism is possible thanks to the page based translation. In the free space between the heap and the stack, most addresses will never be used. In that case, no page table for the translation is created by the OS.
If you generate a random address in a program, the most likely is that it will not correspond to an address mapped by the system to the RAM. If you try any access on this address, the processor will detect that no page exist and will raise an exception that will handled by the system. Most probably the system will stop your program and display an error message like "access violation".
The same mechanism is used to map part of the memory to the disk. To somehow increase the memory size, the system may swap to disk part of the physical memory assigned to a process, in order to allocate it to another process. If the first process tries to access it, again an exception will be raised, but the OS will detect that the address corresponds to a memory zone this stored to disk. It will read the disk, determine a physical address for this page, fill the corresponding page table, restore the memory content and go back to the program that can now perform the memory access.
Virtual Address Space is stored in hard disk. Okay, but where? There are two files that the process uses for this. One of them is the page file, and the other is the swap file.
But what is the difference between the page file and swap file?
The swap file is used when the memory is completely used up and the process needs more memory. So, the swap is an extended part of the memory. The other utility of the swap file is to switch context between processes. So, for instance, imagine Process A is performing, and Process B is waiting to run. Then, before Process B runs, Process A is removed from the actual context e store in the swap file to wait for its time to run again.
Then we have the page file. The page file is used to store the pages that the process is not using in this moment. It is used to save memory because this is a limited resource in the PC. Thus, only pages recently used are present in the actual memory. When the CPU tries to access a page that is not present in the memory, the CPU has a exception, which is handled by the Windows, thus restoring the page in memory, updating the page table, and letting the CPU continue performing the process.
The virtual address space is kept in secondary storage (disk). The virtual part of virtual memory means that the operating system maintains an image of the address space in secondary storage. Because an image of the address space is kept in secondary storage, it can be larger than the physical memory.
The second piece of implementing virtual memory is logical address translation that takes place entirely in memory. In the logical address space, memory is subdivided into pages (something like 512bytes to 1MB). Physical memory is subdivided into page frames. The size of a page frame has to match the size of the logical page on most systems.
The operating system maintains a page table for each process. The page table maps pages in the logical address space to physical page frames. An address consists of an index into the page table and an offset into the page used once the page is located.
In most cases there is no mapping of a logical address to a physical address. If you access a page that has no mapping the processor generates a page fault. Once the logical translation fails, the operating system has to do a virtual translation of the page. It looks to see if the page in question is located in secondary storage.
If the page does not exist, the operating system triggers an access violation exception. If the page does exist, the operating system loads the page into a free physical page frame; updates the page to map the page to that page frame, then restarts the process that caused the fault.
A virtual memory implementation has to maintain a copy of each process's virtual address space in secondary storage. It has to be able to translate logical page references into the virtual page stored on disk. It has to be able to copy logical pages in memory between virtual pages on disk.
You can have logical memory translation without virtual memory translation but you cannot have virtual memory translation without logical memory translation.
When OS is executing some process and then interrupt occurs will there be entry created in page table? How MMU does virtual to physical address conversion of ISR when interrupt occurs?
The processor uses the page tables for the currently running process. Those page tables should define the system address space range that will be the same for all process so it does not matter what process is running at that time.
When OS is executing some process and then interrupt occurs will there be entry created in page table?
What sort of interrupt are you asking about? Speculatively speaking interrupt handler could modify mmu page tables. Not likely that happens in real life though unless that's a page fault interrupt. You better have all used memory properly mapped.
How MMU does virtual to physical address conversion of ISR when interrupt occurs?
Absolutely the same way as for ANY other virtual-to-physical translations, via mmu page tables.
Suppose that you have a 64-bit system and that your OS is scheduling two processes on it. Assume that the core has access to a 4-entry TLB for 4KB page size, and full associativity. Furthermore, assume that the core has a 64-byte direct-mapped cache with 16 byte cache lines. Now suppose that your processes, A and B, have
the following page tables:
Process A Page Table
Now suppose that your OS schedules process A and in it, memory references to the following virtual address are made.
0x2002
For the memory reference presented above, detail all TLB access(whether they are hits or misses) and all cache accesses(whether they are hits or misses). Assume hardware page table walks and a physically addressed cache.
We usually learn Virtual memory and Paging at the same time in Operating System and they seem dependent. However, I wonder if they exist independently of each other?
The answer to your question depends on how you define "Virtual Memory". If you define it just as "the addresses that the application sees", then yes Virtual Memory can exist without paging.
Prior to paging, systems used segmentation to isolate user processes. To put it in simple words every process has it's own segment. All the addresses it "sees" are just offsets inside the segment. The hardware implicitly adds the segment base to the address requested by the application to get the Physical addresses. Just like the page table, the segment bases can be modified only by the kernel and it can effectively isolate memory for processes at the same time allowing scope for sharing some parts of memory between processes too.
Segments also have limits which are checked before every access to ensure that the user doesn't use a very big offset and spill into other process.
Segmentation support has been removed from Intel X86_64 architectures where the segment registers do exist but are always set to 0. Only the two segment registers %fs and %gs continue to exist. But the limit checks on them is not performed by the hardware. These segments are now used by the OS for thread local storage.
This is an interview question I found in a website, the questions says: "In virtual memory, can two different processes have the same address? When you answer "No" which is correct, how one process can access another process' memory, for example the debugger can access the variables and change them while debugging?"
What I understand is :
2 diff process can have same virtual memory address. This is because each process has its own page table. Each process thinks it as 4Gb memory on a 32-bit machine. So both P1 and P2 can access address 0xabcdef - but the physical memory location might be different. Isnt this right ?
The debugger works on the same principle - 2 processes can access the same address. So it can modify variables etc on the fly.
Theoretically every process executed by user in any present popular OSes(Win,linux,unix,Sol etc) are initially allowed to use the address range of 4gig ( 0x00000000 t0 0xffffffff on 32 bit platform),whether its a simple hello world program or its complex web container hosting stackoverflow site.It means every process has its range starting from the same start address and ending with the same address space VIRTUALLY. So obviously every process has that same virtual addresses in their respective virtual address space range. So answer for your first question is YES.
Difference comes when OS execute any process, modern OSes are multitasking OS and they run more than one process at any point of time.So accommodating 4gig of every process in the main memory is not feasible at all. So OSes using paging system,in which they divide the virtual address range (0x00000000 to 0xffffffff) into a page of 4k size(not always). So before starting the process it actually load the required pages which needed at the initial time to the main memory and then load the another virtual page ranges as required. So loading of virtual memory to physical memory (main memory) is called memory mapping. In this process you map the page's virtual address range to physical address range( like ox00000000 to ox00001000 virtaul address range to 0x00300000 to 0x00301000 physical address range)based on the slot free in the main memory.So at any point of time only one virtual address range will be mapped to that particular physical address range,so answer for your second question is NO.
BUT
Shared Memory concept is an exception where all the process can share some of their virtual address range with each other,that will be mapped to a common physical address space.So in this case answer can be YES.
As an example on Linux every executable require libc.so library to execute the program executable.Every process load their required libraries and allocate them some virtual address page ranges in their address space. So now consider a scenario where you are executing 100's of process where each process require this library libc.so. So if OS allocate virtual address space in every process for this library libc.so,then you can imagine the level of duplication for library libc.so & its highly possible that at any point of time you will get multiple instance of libc.so address range pages in the main memory.So to make is redundant OS will load libc.so to specific virtual address space range of every process which is mapped to a fixed physical address range in main memory.So every process will refer to that fixed physical address range to execute any code in libc.so. So in this case every process share some physical address ranges as well.
But there is no chance of two process has same physical address at the same time in the user malloced virtual address range mapping.
Hope it helps.
1)
Same physical memory address at the same time: NO
Same virtual memory address at the same time: YES (each one maps to differnet physical address, or swap space)
2) I think the debuggers don't access directly the other process debugged but communicates with the runtime in the debugged process to do that changes.
That said, maybe the OS or processor instructions provide access/modify to other's memory access if you have the right. That doesn't mean it has the SAME address, it only says process 1 can say "access memory #address1 in Process2". Someone (processor / OS / runtime) will do that for process 1.
Yes, it's definitely possible for the same address to map to different physical memory depending on the process that's referencing it. This is in fact the case under Windows.
Each process has a address space of 4GB in a 32 bit system. Where is this real 4GB is managed by the OS. So in principle 2 different process can have same addresses that is local to the process.
Now when one process has to read the memory of another process it has to either communicate with the other process (memory mapped files etc.,) or use the Debug apis like OpenProcess/ReadProcessMemory.
What I am sure is one process cannot directly go and read the virtual memory of other process atleast in Win32 without the help of the OS.
Sometimes I feel like the "elder" in the Minolta commercial... In the 1960's Multics was created using Virtual Memory. The last Multics system was shut down October 30, 2000 at 17:08Z.
In Multics, only one copy of any program was present in memory, regardless of how many users were running it. So that means that each user process had both the same physical and virtual address for the program.
When I look at the Windows Task Manager and see multiple copies of a program (e.g. svchost.exe) I wonder why / how the revolutionary concepts in Multics were lost.