The top-level page table will not occupy all its table items. What happens when I access a table item with "in / out of place" of 0?
I see that the processing method given in the book is to force a page missing interrupt, but this page missing interrupt is different from what I think. It may directly end the process. Why not remap it?
In addition, if the access to the top-level page table is random (I think the virtual address can be large), For example, in this case in the figure, it is obvious that there are many empty table items in the top-level page table.Isn't it easy to miss?
I think I can extract the key point of the problem, that is, is there a certain virtual address after the program is compiled? Can the operating system try to ensure that it does not cross the border to access unmapped addresses?
I think I have found the answer. After compiling, the program will set logical addresses for them, and the page table items of the top-level page table also correspond to the logical memory distribution of the program. For example, the program body is at the bottom, the corresponding page table item is 0, and the last item of the page table corresponds to the stack area of the program. Once the program accesses the page table items without mapping, it means that it accesses an address area that should not be accessed, I wonder if my idea is correct?
I'm sorry that my English level may make it difficult for you to understand. Thank you for your answer!
Related
I can't figure out what exactly represent fragmentation for a postgres index. in the source code of pgstattuple I found this comment but it's not particularly clear for me.
/*
* If the next leaf is on an earlier block, it means a
* fragmentation.
*/
Btree leaf pages form a logical chain (a doubly linked list) and if you follow that chain in the forward direction you encounter the key values in sorted order. They also have a "physical" order, their block number within the file. That extension considers it fragmentation if the next page following the linked list is to a "physically" earlier page in the file.
You could quibble with this for any number of reasons, but this is the definition that that extension adopted. For example if the logically next page by the linked list is 100 pages forward, that is just as much fragmented as if it is one page backwards. But if it does skip forward a bunch then someone else must be pointing backwards to pick them up (unless they are unused) so would get counted when that "someone else" is encountered. Also, the "physical" order of pages in the file is really just the "logical" order of another layer of abstraction (the file system) and different file systems handle it differently.
I've read three different OS reference books (Stallings, Tanenbaum and Silberschatz) but none of them, from what I've understood, clearly indicates the content type of the outer page in a double paging scheme. In general, the outer page table makes us "find" the inner page table. But does it contain a raw physical address or something else ?
I'm currently following a OS university course, and for an exercise I have to calculate the size (bytes) of an outer page table of 16 elements, the only way I see for an outer page table to make us find an inner page table is to give us a physical address (in this case a physical address is 12 bits long), so I deduct a outer page table is 16*(12+1) bits long (+1 is for validity bit), but the correction states the size is actually 16*(4+1) because the outer page return the number of the page table (I frankly don't know how the number of the page would allow us to retrieve it in any way and I couldn't get a meaningful explanation).
I got an answer from a university Professor : There is several ways to do it, in my exercise it was proposed that the outer page table would be an "array of array", it's simple to implement but unrealistic as an array of array can be too big to be stored effectively. So a more realistic way to do this is by storing physical address pointers to the inner page tables. As the OS can't predict where these addresses will be stored beforehand, it has to use the system reserved memory that will be fixed in advance (the "low memory", I don't know the correct terminology in English for this), and thus it will be able to use raw physical addresses.
I am trying to create a table in a PDF document with itext7. But, if the content before the table is too big, the table gets split up between current page and next page. I want to insert a -
document.Add(new AreaBreak())
if there is not enough space left in the current page for the table to be inserted completely. However, I have no idea on how to calculate the available space.
Any help or pointers will be highly appreciated.
From your requirement to avoid page-break inside the table, I assume Table#setKeepTogether(boolean) is exactly what you need.
This property ensures that, if it's possible, elements with this property are pushed to the next area if they are split between areas.
This is not exactly what you have asked, however it seems it's what you want to achieve. Manually checking for this use case might be tricky. You would need to have a look at renderers mechanism and inner processing of iText layout in order to get available space left and space needed for the table. You would also need to take care of the cases like if table is to big to be fit on single page. Also #setKeepTogether(boolean) works when elements are nested inside each other.
I try to design database tables for the case shown below. I also have an account defined, but it's not important regarding my problem.
There is a list of operations (expenses). Each operation can take place in specified POI, places can be grouped in chains (optional). Each operation can have a recipient, specifically a shop chain.
My current design looks like below. I could even remove chain table in favor of direct reference to recipient, but it still leaves a loop between tables. Effectively, single row could contain references to place and receiving account having different recipient defined.
The only solution I can see is a table check to exclude described case, but I'm wondering: is there a better fix?
As far as I can tell there isn't anything fundamentally wrong with your design. There's no need to change it just because it contains a loop. The loop in this case doesn't even appear to be a circular dependency. If you believe your current design accurately models what it is intended to then I see no need to change it.
In an OS that uses virtual memory, each process has a page table. Each page table maps a process's virtual memory pages to the system's physical memory pages and indicates whether a given page is currently valid (loaded in memory) or not.
Suppose that memory is running low and the OS needs to choose a page to evict from physical memory. There are different algorithms for this. For example, FIFO, LRU. Once the OS chooses a page to evict, how does it invalidate any existing references to the page?
If the victim page is currently used by the active process, then the OS must invalidate the mapping in the current process's page table. If the victim page is currently used by another process, the OS must invalidate the mapping in the other process's page table. In any case, how does the OS determine which page table to update (if any), and how does it know where the mapping lives in that page table without doing a linear search?
There is a detailed description of x86 page table structure beginning at slide 22 of this presentation:
http://www.scs.stanford.edu/12au-cs140/notes/l8.pdf
I also found some helpful overviews of virtual memory:
http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/9_VirtualMemory.html
http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Memory/virtual.html
Similar Stack Overflow question without an answer:
how does linux update page table after context switch
Actually, the thing you are asking about called reverse mapping. For example, in Linux, you can find usefull function try_to_unmap_anon Inside page descriptor there is a field called mapping. This field is anon_vma for annonymous pages. As you can see this is not just ordinary struct, but also a list entry. There might be several anon_vmas for one page (see try_to_unmap_anon):
list_for_each_entry(vma, &anon_vma->head, anon_vma_node)
exactly one per page mapping. All this vmas linked into list. That is how kernel knows which processes (and their page tables) are in play.
Now about how kernel determines the virtual address ... again the answer could be found here: vma_address
233 pgoff_t pgoff = page->index << (PAGE_CACHE_SHIFT - PAGE_SHIFT);
234 unsigned long address;
235
236 address = vma->vm_start + ((pgoff - vma->vm_pgoff) << PAGE_SHIFT);
So we can answer your question shortly now: in order not to do the page tables scan, kernel stores everything it needs (for quick fetch) in page descriptor (struct page).
Usually an OS will pick a process for whom to reduce memory first. Then it will pick pages from within that process. Then it knows the page table to use.
You suggest picking a page then finding which process. That normally occurs in systems that have pageable kernels. In that case, the system page table is shared by all processes.