In some system, paging mapped a virtual address (a8b43fââ)16 to a physical address (13efd43f)16.
What can be inferred about the page size?
While this is not enough information to determine anything for certain, you can infer an upper limit on the page size by noting that the lower 13 bits of both addresses are the same. As we know the page index is the lower x bits of the address, if we find the maximum page index, we can determine the maximum page size. 0x00A8B43F and 0x13EFD43F share the same lower 13-bits ('b1_0100_0011_1111). Thus, the maximum the page size can be is 2^13 words, or 8 kwords. If the memory is byte addressable, this means a page size of 8KB.
However, without more information, knowing the exact page size is not possible as the shared bits might have come from a convenient mapping.
Related
Pagination in some processor make it possible to map virtual address
(A2345678) to physical address (823C5678). However, it is not possible
to map virtual address (345678) to (2ABC678). What can we conclude
about size of frame, page, size of virtual memory, size of physical
memory.
What I think about it:
(A2345678) -> (823C5678)
So, size offset is most 19 bits. We know that size of page (and frame) has size at most 219, like in my previous question.
When it comes to size of virtual memory, and physical memory - I can conclude nothing.
Similary, I don't know what tell me information about non-possibility mapping address.
Can you try to explain it me ?
I do see something we can conclude after all:
If a mapping to physical address 0x823C5678 is possible, physical memory is at least that large. (Assuming there aren't any holes in physical address space; not a good assumption on real hardware, but whatever. We can tell that physical address space is at least that big, even if it doesn't all map to DRAM or MMIO).
Similarly, the valid virtual address 0xA2345678 gives us a lower bound on the virtual address size. Presumably all the virtual address bits can be 1, so the highest possible virtual address is at least 0xFFFFFFFF. i.e. virtual addresses are at least 32 bits, but could be any larger size.
This reasoning applies to physical address space, but not the size of physical memory. (e.g. in a computer with 19GiB of RAM, the highest valid physical address isn't 2n-1.)
The fact that you can't map 0x345678 to 0x2ABC678 does tell us that the page size is greater than 212. The physical address is below the address that was mappable, so we can rule out that possible reason for the mapping being impossible. I think too high and misaligned are the only possible reasons for a mapping not being possible.
(0xc = 0b1100, while 0x5 is 0b0101, so the common bits are only 0x678.)
We can assume that physical memory is a whole number of pages, so we can round up the lowest possible end of physical memory to the next multiple of 213.
We have question:
Calculate the maximum and minimum sizes of a single 3-level page table
for a 32-bit machine with a 4kB page size. The partitioning of the 20
bits representing a virtual page in this 3-level pge table is: (7, 7,
whatever bits remain).
I understand that minimum size should be 4k+4k+4k=12k because a process needs to have at least one frame allocated for itself. However I'm confused as to how to calculate the maximum. It works nicely with 2-level page tables because we can slice the 20 bits into 10 and 10 which works out nicely to 1024 entries * 4 bytes each which is a nice factor of 4k. But with 2^7 entires we get a strange number, any ideas on how to solve? Thanks.
Sadly, your question does not have an answer. This type of question is typical of the horrible operating systems textbooks out there.
First of all, you have no indication of the page table entry. Is is 32bits? 64bits? Are the entries the same size at each level of the page table?
It's not really possible for a process to have a 0-byte page table. There would need to be a least one page mapped for the process to executive. A minimum would then be 3 page table entries of whatever unspecified size (probably something like 12-bytes).
At to the maximum, that depends upon how the hardware and OS divides up the address space.
Excluding the valid, dirty and reference bits, considering only actual "mapping" from virtual address space to physical address space, why is it said that the size of a page table entry is determined by the number of bits required to reference a page from the main memory (Like here: https://stackoverflow.com/a/14770650/3684931)
My argument is that since a physical address can be in secondary storage too (which is the point of using virtual memory), the size of a page table entry should simply be equal to the number of bits to required to reference any page among all the pages in the virtual memory.
To give an example, if virtual address space is addressable by 64 bits, main memory is addressable by 48 bits and page size is 16KB (addressable by 14 bits), a page table should map (64 - 14) 50 bit addresses to (64 - 14) 50 bit addresses and not (48 - 14) 34 bit addresses.
It could map to 34 bit addresses if the page exists in main memory, but otherwise, the upperbound should be 50 bits which should be considered while calculating the size of a page table.
Am I missing something here?
Page table entries are sized to support the virtual address size and the maximum amount of physical memory supported. They are not sized based on any aspect of the secondary storage.
In your example, the page table has to support mapping 2^50 virtual pages to a possible 2^34 physical pages. Thus a page table entry will use 34 bits to hold the physical page number.
If a page is not present in memory, and it was previously paged out to secondary storage, then a data structure (like a hash table) can be used to locate where in the paging file the page is located. You don't need to use the page table structure to do this.
The size of a page table must account for:
1. Control bits
2. Access restriction bits
3. The page size
4. The number of bits requires to access the required number of pages.
The page table entries correspond to the virtual memory. The number of entries times the page size is the virtual address size.
The entries themselves only need to address physical memory.
I have been given the format for page table entries:
Bit 23: Valid Bit
Bit 22: Modify Bit
Bits 22-18: LRU Bits
Bits 17-0: Frame Number
Im told that the system uses 32-bit virtual addresses and pages that are 8192 bytes in size.
What would be the total size in bytes of the page map table?
If an inverted page map table is used what would be its total size in bytes if the LRU field within each PTE is reduced to 3 bits?
I have been helped with this problem, and calculated that the maximum physical memory of the system is 2GB. I'm not sure if I need to take the 32 bit virtual address data given into consideration when calculating the total size of the page map table.
Looks like there isn't enough information to answer this question.
See, the page table size is equal to the number of entries in it times the size of each entry.
First, I don't know if the page table entries are 24-bit-long or 32-bit-long or bigger. That's not explicitly specified.
Second, if there's only one page table involved in translation of virtual addresses into physical addresses, a page table has to cover the entire 32 bits of the virtual address. Since a single PTE only handles 13 (because the page size is 2^13=8192 bytes), you'd need 2^(32-13)=2^19 entries in this case.
Now, if there's a hierarchy of page tables involved in the translation, in other words, the entries of the first page table (often called page directory) point to a second-level page table and those either point to the code/data pages or to a third-level page table and so on, you get the idea... in this case the answer is going to be different. But it's not specified whether there's just one page table or a chain of multiple page tables.
In my opinion, a page table of 2^19 entries is unlikely. A page table is usually the size of a single page (sometimes smaller). So, if, for example, PTEs are 32-bit, you have 8192/4=2048 PTEs in a PT and that covers only 11 (2^11=2048) out of the remaining 32-13=19 bits of the virtual address. The other 19-11=8 bits of the virtual address must be taken care of by another page table, page directory, having only 2^8=256 entries, provided the entries are the same in the page table and page directory.
Given the provided information, there's no definitive answer here, only guesses.
I was reading up on Virtual Memory and from what I understand is that each process has its own VM table that maps VM addresses to Physical Addresses in real memory. So if a process allocated objects continuously they can potentially be stored in completely different places in Physical Memory. My question is that if I allocate and array which is supposed to be stored in a contiguous block of memory and if the size of the array requires more space than one page can provide, from what I understand is that array will be stored contiguously in VM but possibly in completely different location in PM. Is this correct? please correct me if I misunderstood how VM works. And if it is correct does that mean we are only concerned whether allocation is contiguous in VM?
Whether or not something that overlaps a page boundary is actually contiguous in Physical Memory is never really knowable with modern memory handlers. Memory glue logic essentially treats all addressable memory pages as an unordered set, and the ordering is essentially associated with a process; there's no guarantee that for different processes that end up getting assigned the same two physical memory pages (at different points in time) that the expressed relationship between those physical pages will be the same. Effectively, there's a translation layer between the CPU and the memory that handles this stuff.
That's right. Arrays must only looks contiguous for your application, but may be physically scattered on memory.
I just wanted to add/make it clear that from a user space program's point of view, a chunk of allocated memory always appears contiguous. The operating system in conjunction with the CPU's Memory Management Unit (MMU) handles all virtual to physical memory mappings and the programmer never needs to worry about how this mapping is handled (unless, of course, said programmer is writing an operating system).
A compiler (or one who writes code in assembly) can treat a program's addresses as starting from 0 and going up until the largest address needed for that particular program. The operating system then creates a page table for each process and uses this table to partially decode a physical address for each virtual memory location. The OS treats an address in a program as two separate parts, the page address and the offset into that page. Then, the MMU translates a page address into a physical frame address. Note that a physical memory "frame" is analogous to the conceptual "page" from the standpoint of the OS; these two are of the same size (eg 4096 bytes).
Since physical memory is divided into equally sized frames, and page size is the same as frame size you can know how much of your virtual address is used as a page location and how much is an offset into that page. For instance, if your OS "allocates" 4 gigabytes to each process (as is the case in Linux), and your page/frame size is 4096 bytes, you can know that 20 bits (4,294,967,296 bytes / 4096 bytes = 2 ^ 20 = 1,048,576 pages/page addresses) of a 32 bit address are used as a page address, which will then be converted to a physical frame address by the MMU, and the remaining 12 bits are used as an offset to determine the location of the address starting from the beginning of the page/frame.
VM (user pace) address --> page + offset (OS) --> frame + offset (MMU) = physical address