From what I understand, demand paging is basically paging with swapping, so you can swap in a page when it is needed. But page replacement seems like more or less the same thing, where you bring in a page is needed and switching it with an existing page in physical memory.
So is there a distinct difference?
In a system that uses demand paging, the operating system copies a disk page into physical memory only if an attempt is made to access it and that page is not already in memory (i.e., if a page fault occurs). It follows that a process begins execution with none of its pages in physical memory, and many page faults will occur until most of a process's working set of pages is located in physical memory. This is an example of a lazy loading technique.
From Wikipedia's Demand paging:
Demand paging follows that pages should only be brought into memory if
the executing process demands them. This is often referred to as lazy
evaluation as only those pages demanded by the process are swapped
from secondary storage to main memory. Contrast this to pure swapping,
where all memory for a process is swapped from secondary storage to
main memory during the process startup.
Whereas, page replacement is simply the technique which is done when there occurs a page-fault. Page replacement is a technique which is utilised for both pure swapping and demand-paging.
Page Replacement simply means swapping two processes between memory and disk.
Demand Paging is a concept in which only required pages are brought into the memory. In case where a page required is not in the memory, the system looks for free frames in the memory. If there are no free frames, then a page replacement is done to bring the required page from the disk to the memory.
Related
Can someone clearly explain me the difference between a cache miss, a tlb miss and page fault, and how do these affect the effective memory access time?
Let me explain all these things step by step.
The CPU generates the logical address, which contains the page number and the page offset.
The page number is used to index into the page table, to get the corresponding page frame number, and once we have the page frame of the physical memory(also called main memory), we can apply the page offset to get the right word of memory.
Why TLB(Translation Look Aside Buffer)
The thing is that page table is stored in physical memory, and sometimes can be very large, so to speed up the translation of logical address to physical address , we sometimes use TLB, which is made of expensive and faster associative memory, So instead of going into page table first, we go into the TLB and use page number to index into the TLB, and get the corresponding page frame number and if it is found, we completely avoid page table( because we have both the page frame number and the page offset) and form the physical address.
TLB Miss
If we don't find the page frame number inside the TLB, it is called a TLB miss only then we go to the page table to look for the corresponding page frame number.
TLB Hit
If we find the page frame number in TLB, its called TLB hit, and we don't need to go to page table.
Page Fault
Occurs when the page accessed by a running program is not present in physical memory. It means the page is present in the secondary memory but not yet loaded into a frame of physical memory.
Cache Hit
Cache Memory is a small memory that operates at a faster speed than physical memory and we always go to cache before we go to physical memory. If we are able to locate the corresponding word in cache memory inside the cache, its called cache hit and we don't even need to go to the physical memory.
Cache Miss
It is only after when mapping to cache memory is unable to find the corresponding block(block similar to physical memory page frame) of memory inside cache ( called cache miss ), then we go to physical memory and do all that process of going through page table or TLB.
So the flow is basically this
1.First go to the cache memory and if its a cache hit, then we are done.
2. If its a cache miss, go to step 3.
3. First go to TLB and if its a TLB hit, go to physical memory using physical address formed, we are done.
4. If its a TLB miss, then go to page table to get the frame number of your page for forming the physical address.
5. If the page is not found, its a page fault.Use one of the page replacement algorithms if all the frames are occupied by some page else just load the required page from secondary memory to physical memory frame.
End Note
The flow I have discussed is related to virtual cache(VIVT)(faster but not sharable between processes), the flow would definitely change in case of physical cache(PIPT)(slower but can be shared between processes). Cache can be addressed in multiple ways. If you are willing to dive deeply have a look at this and this.
This diagram might help to see what will happen when there is a hit or a miss.
Just imagine a process is running and requires a data item X.
At first cache memory will be checked to see if it has the requested data item, if it is there(cache hit), it will be returned.If it is not there(cache miss), it will be loaded from main memory.
If there is a cache miss main memory will be checked to see if there is page containing the requested data item(page hit) and if such page is not there (page fault), the page containing the desired item has to be brought into main memory from disk.
While processing the page fault TLB will be checked to see if the desired page's frame number is available there (TLB hit) otherwise (TLB miss)OS has to consult page table for servicing page fault.
Time required to access these types memories:
cache << main memory << disk
Cache access requires least time so a hit or miss at certain level drastically changes the effective access time.
What causes page faults? Is it always because the memory has been
moved to hard disk? Or just moved around for other applications?
Well, it depends. If your system does not support multiprogramming(In a multiprogramming system there are one or more programs loaded in main memory which are ready to execute), then definitely page fault has occurred because memory has been moved to hard disk.
If your system does support multiprogramming, then it depends on whether your operating system uses global page replacement or local page replacement. If it uses global, then yes there is a chance that memory has been moved around for other applications. But in local, the memory has been moved back to hard disk. When a process incurs a page fault, a local page replacement algorithm selects for replacement some page that belongs to that same process. On the other hand a global replacement algorithm is free to select any page in from the entire pool of frames. This discussion about these pops up more when dealing with thrashing.
I am confused of the difference between TLB miss and page faults.
TLB miss occurs when the page table entry required for conversion of virtual address to physical address is not present in the TLB(translation look aside buffer). TLB is like a cache, but it does not store data rather it stores page table entries so that we can completely bypass the page table in case of TLB hit as you can see in the diagram.
Is page fault a crash? Or is it the same as a TLB miss?
Neither of them is a crash as crash is not recoverable. But it is well known that we can recover from both page fault and TLB miss without any need for aborting the process execution.
The Operating system uses virtual memory and page tables maps these virtual address to physical address. TLB works as a cache for such mapping.
program >>> TLB >>> cache >>> Ram
A program search for a page in TLB, if it doesn't find that page it's a TLB miss and then further looks for the page in cache.
If the page is not in cache then it's a cache miss and further looks for the page in RAM.
If the page is not in RAM, then it's a page fault and program look for the data in secondary storage.
So, typical flow would be
Page Requested >> TLB miss >> cache miss >> page fault >> looks in secondary memory.
What happens to dirty cache lines which are not yet written back (assuming write-back cache), when the page it is part of is chosen for eviction by the Operating System. In other words what happens to the cache lines of the page, when a page is chosen for eviction from main memory.
The general assumption is that by the time the page is evicted from memory it is cold enough not to be cached. However would this pose a problem in larger caches? If say we have enough cache lines to fit 1 line from each page?
Nothing will directly happen to the cache lines. In an operating system, we must always assume the worse of the possibilities, and even small caches could face your proposed scenario. However, the operating system does not need to do anything directly to the cache lines, the normal process of paging will handle this scenario.
When the operating system decides to evict a page, it will first write its contents out to disk (as the processor would have marked the page table entry as dirty indicating that the page has been written to). In the process of doing so, the OS will read the values from the entire page including the dirty cache lines, so they will be written back, at least to disk.
Next as part of evicting the page, the operating system will invalidate the translations that map the virtual to physical addresses. Even if the cache lines are still dirty, they can no longer be accessed by the process (i.e., program). After this step, the operating system will write different data into the physical page, and this action will invalidate the cache lines. Finally, the newly repurposed physical page will be mapped to a virtual address.
Under Windows, the kernel can swap a physical memory page to a page in the paging file.
For simplicity, we assume there is only one paging file.
As far as I understand, the paging file consists of pages which have the same size of a physical memory page. i.e. 4K.
I just wonder:
How does the kernel know which page in the paging file is free to store?
(Free here means the page in the paging file doesn't previously store another physical memory page.)
At the risk of gross oversimplification . . . the usual approach in implementing virtual memory is that disk is the primary storage. Unless there is a mapping to a file, a virtual page does not exist. That mapping remains fixed for the life of the process.
The virtual memory on disk gets mapped to physical memory when available.
The kernel maintains some data structure (e.g. a bitmap) to indicate the free areas of the page file and other structures to maintain the mapping of logical addresses to the files.
I believe you are asking about page replacement algorithms within memory management.
When the operating system needs to save a new page in memory and keep track of its information on the paging file (also known as the page table), there's no guarantee that there will be a free spot --meaning that other pages' information might have taken up all of it. In that case, the OS will have to evict an existing page. The OS doesn't need free space since, if there isn't any, it will make it.
If you're interested in learning more (this is a pretty large topic), you may find the lecture notes from NYU's "Operating Systems" class helpful. This is the demand paging unit, and further below you can read about a few page replacement algorithms ("WS Clock" and "Aging" are probably the most important).
Hopefully this is helpful!
Are .text pages in a process' memory swapped-out, or is it just the pages containing data (heap) that are swapped-out?
Here by "swapped-out" I refer to 'being swapped to the swap area' and not 'mere eviction from primary memory'. My doubt is whether the .text pages are merely evicted and then read from the HDD as they are never to be modified (unlike data pages), or are they swapped to swap area.
So also, is a page belonging to stack swapped-out?
Can anyone please provide more clarity on what pages in the virtual memory of a process are considered for swapping, and which ones are never?
All pages in the end are considered for being swapped out. In Linux it starts by swapping out freeing cache pages followed by clean non-recently used pages (which just requires unmapping rather than a write to the swap device). After this it will try to flush dirty file backed pages in memory to their respective backing device before finally reaching the point where it must starts swapping anonymously backed process pages (includes stack, data that can be edited, heap, etc....). Any non-kernel page is always a candidate for being swapped out it just depends on the memory pressure on the system.
Pages that already have a backing store are simply unmapped or if they are dirty are flushed to their backing store. They are not written to swap for obvious reasons.
So I'm in a computer architecture class, and I guess I'm having a hard time differentiating between caching and pages.
The only explanation I can come up with is that pages are the OS's way of tricking a program that it's doing all it's work in a specified region of memory, vs a cache memory is the hardware's way of tricking the OS that it's reading from one specified region of memory, when it's really not.
Does the os direct the hardware that it needs a "new page" or is that taken care of by the os trying to read the address that is "out of range" of the current cache "page" (for lack of a better term).
Am I on the right track or am I completely crazy?
Caching and pages are orthogonal concepts.
A cache is a high-speed "memory" that acts to minimise the number of accesses to a large low-speed "memory". In the most general sense, the high-speed "memory" could be your hard disk acting to cache web pages fetched from the web (low-speed "memory"). Of course, in the context of computer architecture, the term "cache" is more likely to refer to physical RAM used to speed up access to slower RAM or disk.
Pages, OTOH, are simply a unit of management for the contents of RAM or disk.
These two concepts come together in implementing virtual memory systems. A process may allocate 500 MB of memory. This may be more that the physical RAM available to give to the process, so the operating system allocates blocks on disk called pages, which will hold the contents of certain logical pages in the process's address-space.
When the process accesses a location in its address-space, and the associated page isn't currently mapped into physical memory, the CPU signals a page fault, and the OS responds by fetching the page from disk while the process is in a suspended state. Once the page is mapped, the process resumes and is able to access that memory location as if it was there all along.
The common view that virtual memory is a way of tricking the process into thinking it has tons of RAM isn't the only way to think about this. You could also think of a process's address-space as being logically stored on disk pages, with the OS-assisted mapping into RAM being just a way to cache the contents of those pages such that the process isn't continually accessing the hard drive. In this sense, caching and paged virtual memory are logically the same thing. Just keep in mind that, while this viewpoint may help to understand the relationship between the two concepts, it isn't entirely accurate, since it is possible to run without virtual memory at all, just physical memory (in fact, most embedded systems run this way).
I think Paging is bring instruction data from disk or secondary memory to the main memory while caching is bring instruction data from main memory to CPU