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.
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.
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.
When a page is swapped out to disk, some of its content might be present in a cache (I believe this would be a very rare scenario, because, if the page is not accessed for a long time, most likely the cache-lines containing its content would also have been evicted by then.) What happens to these cache-lines when the page is swapped out. Do they need to be invalidated immediately ? Does it make any difference if the line is dirty or clean ? Who controls this process, OS or hardware or both ?
To explain why this need be taken care of, lets assume there are processes A & B and A is accessing physical page P1 at starting physical address X. Some of the contents of P1 must have been cached in different levels of caches. Now the page P1 is swapped out and page P2 of process B is brought in at the same address X. So if the cache-lines belonging to page P1 are not invalidated, then process B might get caches hit on those lines which originally belonged to process A for page P1 (because the physical tag would match).
Is this scenario valid ? Does it make any difference if the cache is VIPT or PIPT ?
It would be great, if you can cite how it is handled in modern OS/Processor.
If DMA (the preferred method of copying data between I/O devices and memory for large transfers) is cache coherent (i.e., the DMA agent checks the cache), then hardware will ensure that any dirty cache lines will be read when paging out and any old cache lines will be invalidated (or overwritten — some systems support I/O devices storing to cache). For non-coherent DMA, the OS would have to flush the page being paged out to memory.
Whether DMA is coherent is ISA and implementation dependent. For example, this blog post mentions that x86 guarantees coherence but Itanium and ARM do not. (Note that an implementation of an ISA can provide stronger guarantees.)
Whether the cache is virtually indexed or not would not impact the operations required because the OS would flush based on the virtual address and aliasing issues would already be handled in hardware or by software (e.g., by page coloring).
When I do VirtualAlloc with MEM_COMMIT this "Allocates physical storage in memory or in the paging file on disk for the specified reserved memory pages" (quote from MSDN article http://msdn.microsoft.com/en-us/library/aa366887%28VS.85%29.aspx).
All is fine up until now BUT:
the description of Committed Bytes Counter says that "Committed memory is the physical memory which has space reserved on the disk paging file(s)."
I also read "Windows via C/C++ 5th edition" and this book says that commiting memory means reserving space in the page file....
The last two cases don't make sense to me... If you commit memory, doesn't that mean that you commit to physical storage (RAM)? The page file being there for swaping out currently unused pages of memory in case memory gets low.
The book says that when you commit memory you actually reserve space in the paging file. If this were true than that would mean that for a committed page there is space reserved in the paging file and a page frame in physical in memory... So twice as much space is needed ?! Isn't the page file's purpose to make the total physical memory larger than it actually is? If I have a 1G of RAM with a 1G page file => 2G of usable "physical memory"(the book also states this but right after that it says what I discribed at point 2).
What am I missing? Thanks.
EDIT: The way I see it is perfectly described here: http://support.microsoft.com/kb/555223
"It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (perhaps both)"
but I have read too many things that contradict my belief like those two points above and others like this one for instance: http://blogs.msdn.com/ricom/archive/2005/08/01/446329.aspx
You're misunderstanding the way windows' memory model works. The terminology and the documentation confuse things a bit which doesn't help.
When you commit memory, the OS is providing you with a "commitment" to providing a page to back that memory. It is not actually allocating one, either from physical memory or from the page file, it is simply checking that the "uncommited pages" counter is larger than zero and then decrementing it. If this succeeds the page is marked as commited in your page table.
What happens next depends on whether you access the memory. If you don't, all you did was stop someone else using a page - it was never actually allocated though so it is impossible to say which page you didn't use. When you touch the memory though a page fault is generated. At this point the page fault handler sees that the page is commited and starts to look for a page that can be used on a number of lists of pages the memory manager keeps. If it can't find one then it will force something else out to the page file and give you that page.
So really a page is never actually allocated until you need it, when it is allocated by the page fault handler. The reason the documentation is confusing is that the above description is quite complicated. The documentation has to describe how it works without going into the gory details of how a paging memory manager works and the description is good enough.
Each page of physical memory is backed by either a pagefile (for volatile pages of memory, such as data) or a disk file (for read-only memory pages, such as code and resources). When I say backed, I mean the behavior/process that when the page is needed, the operating system reads it from the disk file, when it is no longer needed, the operating system frees it and flush the content to the disk file.
When you commit a block of virtual memory, the Virtual Memory Manager(VMM) will allocate you an entry into the process's virtual address descriptor (VAD) tree, and reserve the space in the paging file. The physical memory will only be allocated until this block memory is accessed. In the case that page file is disabled, the space will be reserved in the physical memory directly.
Please refer to these links: Managing Virtual Memory and Managing Memory-Mapped Files