I was studying memory management in OS and suddenly got this doubt. It is said that in pure demand paging, process starts execution with zero pages brought to the main memory. The virtual address space contains many things including data, stack,heap and the text-area or code. So if a process is going to execute and it has no page in main memory,how will Instruction register store its first instruction which will executed by CPU resulting in further page faults?
This is a bad way of viewing the address space.
The virtual address space contains many things including data, stack,heap and the text-area or code.
The address space consists of memory with different attributes: readonly, readonly/execute, read/write and rarely read/write/execute.
Virtual memory is the use of secondary storage to simulate physical memory. The program loader reads the executable file and builds the address space on disk. For example, on some systems the executable file itself became the page file for code and data.
Once the program is loaded, the address space consists of pages that are valid to the operating system but have no mapping to physical addresses.
When the program starts running it accesses valid pages without mappings that results in page faults. The operating system page fault handler finds where the page is stored in secondary storage, maps the page to a physical page frame, and loads the data into the page.
So if a process is going to execute and it has no page in main memory,how will Instruction register store its first instruction which will executed by CPU resulting in further page faults?
The starting instruction is specified in the executable. That value gets loaded into a register. There is no first instruction in memory. When the program tries to execute its first instruction, it gets a page fault.
Related
I find that during TLB missing process, some architecture use hardware to handle it while some use the OS. But when it comes to page fault, most of them use the OS instead of hardware.
I tried to find the answer but didn't find any article explains why.
Could anyone help with this?
Thanks.
If the hardware could handle it on its own, it wouldn't need to fault.
The whole point is that the OS hasn't wired the page into the hardware page tables, e.g. because it's not actually in memory at all, or because the OS needs to catch an attempt to write so the OS can implement copy-on-write.
Page faults come in three categories:
valid (the process logically has the memory mapped, but the OS was lazy or playing tricks):
hard: the page needs to be paged in from disk, either from swap space or from a disk file (e.g. a memory mapped file, like a page of an executable or shared library). Usually the OS will schedule another task while waiting for I/O.
soft: no disk access required, just for example allocating + zeroing a new physical page to back a virtual page that user-space just tried to write. Or copy-on-write of a writeable page that multiple processes had mapped, but where changes by one shouldn't be visible to the other (like mmap(MAP_PRIVATE)). This turns a shared page into a private dirty page.
invalid: There wasn't even a logical mapping for that page. A POSIX OS like Linux will deliver SIGSEGV signal to the offending process/thread.
The hardware doesn't know which is which, all it knows was that a page walk didn't find a valid page-table entry for that virtual address, so it's time to let the OS decide what to do next. (i.e. raise a page-fault exception which runs the OS's page-fault handler.) valid/invalid are purely software/OS concepts.
These example reasons are not an exhaustive list. e.g. an OS might remove the hardware mapping for a page without actually paging it out, just to see if the process touches it again soon. (In which case it's just a cheap soft page fault. But if not, then it might actually page it out to disk. Or drop it if it's clean.)
For HW to be able to fully handle a page fault, we'd need data structures with a hardware-specified layout that somehow lets hardware know what to do in some possible situations. Unless you build a whole kernel into the CPU microcode, it's not possible to have it handle every page fault, especially not invalid ones which require reading the OS's process / task-management data structures and delivering a signal to user-space. Either to a signal handler if there is one, or killing the process.
And especially not hard page faults, where a multi-tasking OS will let some other process run while waiting for the disk to DMA the page(s) into memory, before wiring up the page tables for this process and letting it retry the faulting load or store instruction.
Hello OS experts from Stackoverflow.
I have been struggling to find out whether the page-fault occurs when the OS reads a file for the first time in Intel architecture x86.
I am curious about how the Operating system will handle after the userspace application calls the read syscall after the open syscall.
For my understanding...
After the read system call, the kernel accesses an invalid page of the page table that is not currently mapped by the memory management unit and raises the page-fault.
The page fault will call for demand paging. The Kernel looks up the disk address of the desired page and schedules disk operation (I/O scheduling).
However, I received a tip from my advisor that the page-fault does not occur when the file is opened and read for the first time.
Is this true? I've been searching all over to find a clear answer to this without any success. Would it be possible to explain whether the page-fault happens or not at the first file read?
It depends upon how the file is being read. If the file is being read as a memory mapped file, it is close to a certainty that a page fault will occur.
If being read through a buffer, its is likely the system will require the buffer to be locked in memory. However, there could be a page file when transferring the data to a user buffer.
I am reading Chap9 of Operating System Concepts and the concept of pure demand paging is described as follows:
In the extreme case, we can start executing a process with no pages in
memory. When the operating system sets the instruction pointer to the first instruction of the process, which is on a non-memory-resident page, the process
immediately faults for the page....
But if NONE of the pages, particularly the pages containing code, are in memory, how does the OS know where the program counter is in the first place? Is program counter set as part of process creation by inspecting the program image on disk? If so, I would assume the OS knows the format of the binary image and can directly access that info on disk. And it will only make sense if somehow this info is stored in the part of the program image not needed during program execution, if OS decides not to bring the page containing this info into memory.
To summarize, I would like to know:
How is program counter set for a new process if using pure demand paging?
Is any real OS using pure demand paging and what benefit does it have?
How does an executable's binary format (e.g. ELF, PE formats) help the OS do demand paging (OS needs to know where the first page is at least?)
I am reading operating systems and having a doubt regarding page fault service time ?
Average memory access Time = prob. of no page fault (memory access time)
+
prob. of page fault (Page fault service time)
My doubt is that what does the page fault service time includes ?
According to me,
First address translation is there in TLB or Page table , but when entry is not found in page table, it means page fault occurred . So, i have to fetch from disk and all the entries get updated in the TLB and as well as page table.
Hence, page Fault service time = TLB time + page table time + page fetch from disk
Plz someone confirm it ?
What you are describing is academic Bulls____. There are so many factors that a simple equation like that does not describe the access time. Nonetheless, there are certain idiotic operating systems books that put out stuff like that to sound intellectual (and professors like it for exam questions).
What these idiots are trying to say is that a page reference will be in memory or not in memory with the two probabilities adding up to 1.0. This is entirely meaningless because the relative probabilities are dynamic. If other processes start using memory, the likelihood of a page fault increases and if other processes stop using memory, the probability declines.
Then you have memory access times. That is not constant either. Accessing a cached memory location is faster than a non-cached location. Accessing memory that is shared by multiple processors and interlocked is slower. This is not a constant either.
Then you have page fault service time. There are soft and hard page faults. A page fault on a demand zero page is different in time for one that has to be loaded from disk. Is the disk access cached or not cached? How much activity is there on the disk?
Oh, is the page table paged? If so, is the page fault on the page table or on the page itself? It could even be both.
Servicing a page fault:
The process enters the exception and interrupt handler.
The interrupt handler dispatches to the page fault handler.
The page fault handler has to find where the page is stored.
If the page is in memory (has been paged out but not written to disk), the handler just has to update the page table.
If the page is not in memory, the handler has to look up where the page is stored (this is system and type of memory specific).
The system has to allocate a physical page frame for the memory.
If this is a first reference to a demand zero page, there is no need to read from disk, just set everything to zero.
If the page is in a disk cache, get the page from that.
Otherwise read the page from disk to the page frame.
Reset the process's registers as appropriate.
Return to user mode
Restart the instruction causing the fault.
(All of the above have gross simplifications.)
The TLB has nothing really to do with this except that the servicing time is marginally faster if the page table entry in question is in the TLB.
Hence, page Fault service time = TLB time + page table time + page fetch from disk
Not at all.
In virtual memory management, swap in/out is used for managing page faults and the swap file is in a pre-allocated disk location.
But when it comes to demand paging, say for an example, when loading a program code, how does the virtual memory management system knows the actual location of the next instruction ? Does it map the executable file as a memory mapped file ?
There are actually two separate questions here:
1) How does the OS program loader read an executable from disk and create an address space for the program to run in?
... and ...
2) How does OS virtual memory management work for running programs?
It depends upon the operating system. The description I am giving here is a simplification based upon a number of system.
Executable file describes a number of program sections. The loader reads the executable and uses it to define the sections in memory. For static data and code, the executable becomes the file used for paging (read only). For read only memory, the system page file is used for paging (read/write).
In this model, yes, the executable is a memory mapped file (although only part of it are mapped to memory). Some systems do not support direct paging to the executable.
When the program executes an instruction on a page for the first time, the memory management unit detects that the page is not in memory and that the page is backed to the executable. It then loads the page from the executable file and restarts the instruction. This is why you get a lot of page faults when a program starts up.