A certain computer provides its users with a virtual memory space of 2^24 words. Computer has 2^18 words of physical memory. The virtual memory is implemented by paging, and the page size is 256 words. A user program generates the virtual address 24A72E (HEX). Explain how the system established the corresponding physical location...
Logical Page (i.e. the page table entry) = 24a72Ex / 256
That provides a index to a page table entry. That page table entry identifies the physical memory page.
The word offset into the page is is 24a72Ex MOD 256
Related
If virtual memory has a 32-bit address are there 2^32 entries or is the size of total entries 2^32 bytes? or both?
The reason I ask is because I thought it only meant 2^32 entires.
After doing the following problem I am not sure:
Suppose a machine has 48-bit virtual addresses and 32-bit physical addresses.If pages are 4KiB, how many entries are in the page table if it has only a single level?
Solution: 2^48/2^32 = 2^16 pages.
However, number of entries/size of page != number of pages.
size of total entries/size of page = number of pages.
So, I'm wondering if a 32-bit address means there are 2^32 entries or if total entries equal 2^32 bytes or both.
Jinan, i think you are confused in linux memory related stuff.
your question for :
If virtual memory has a 32-bit address are there 2^32 entries or is the size of total entries 2^32 bytes? or both?
Page table entries are not depend only virtual address space, page size and physical memory are also need to calculate the entries.
I'm taking your example:-
Suppose a machine has 48-bit virtual addresses and 32-bit physical addresses.If pages are 4KiB, how many entries are in the page table if it has only a single level?
Number of entries in page table will be = 2^36.
A page entry is used to get address of physical memory. Here we assume that single level of Paging is happening. So the resulting page table will contain entries for all the pages of the Virtual address space.
Number of entries in page table =
(virtual address space size)/(page size)
Virtual address = 48 Bit
Page size is = 12 bit ((2^12) is equal to 4KB).
Using above formula we can say that there will be 2^(48-12) = 2^36 entries in page table.
Size of Page Table
No. of bits required to address the 32bit Physical memory = 32.
So there will be 2^(32-12) = 2^20 page frames in the physical memory. And page table needs to store the address of all these 2^20 page frames. Therefore, each page table entry will contain 32 bits address of the page frame..
Since memory is byte addressable. So we take that each page table entry is 32 bits i.e. 4 bytes long.
Size of page table =
(total number of page table entries) *(size of a page table entry)
= (2^36 *4) = 256GB
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
Consider a virtual memory system with a 38-bit virtual byte address, 1KB pages and 512 MB of physical memory. What is the total size of the page table for each process on this machine, assuming that the valid, protection, dirty and use bits take a total of 4 bits, and that all the virtual pages are in use? (assume that disk addresses are not stored in the page table.)
Well, if the question is simply "what is the size of the page table?" irrespective of whether it will fit into physical memory, the answer can be calculated thus:
First physical memory. There are 512K pages of physical memory (512M / 1K). This requires 19 bits to represent each page. Add that to the 4 bits of accounting information and you get 23 bits.
Now virtual memory. With a 38-bit address space and a 10-bit (1K) page size, you need 228 entries in your page table.
Therefore 228 page table entries at 23 bits each is 6,174,015,488 bits or 736M.
That's the maximum size needed for a single-level VM subsystem for each process.
Now obviously that's not going to work if you only have 512M of physical RAM so you have a couple of options.
You can reduce the number of physical pages. For example, only allow half of the memory to be subject to paging, keeping the other half resident at all time. This will save one bit per entry, not really enough to make a difference.
Increase the page size, if possible. A 1K page on a 38-bit address space is the reason for the very chunky page tables. For example, I think the '386, with its 32-bit address space, uses 4K pages. That would result in a million page table entries, far less than the 260 million required here.
Go multi-level. A bit more advanced but it basically means that the page tables themselves are subject to paging. You have to keep the first level of page tables resident in physical memory but the second level can go in and out as needed. This will greatly reduce the physical requirements but at the cost of speed, since two levels of page faults may occur to get at an actual process page (one for the secondary paging tables then one for the process page).
Let's look a little closer at option 3.
If we allow 32M for the primary paging table and give each entry 4 bytes (32 bits: only 23 are needed but we can round up for efficiency here), this will allow 8,388,608 pages for the secondary page table.
Since each of those secondary page table pages is 1K long (allowing us to store 256 secondary page table entries at 4 bytes each), we can address a total of 2,147,483,648 virtual pages.
This would allow 8,192 fully-loaded (i.e., using their entire 28-bit address space) processes to run side by side, assuming you have a fair chunk of disk space to store the non-resident pages.
Now obviously the primary paging table (and the VM subsystem, and probably a fair chunk of the rest of the OS) has to stay resident at all times. You cannot be allowed to page out one of the primary pages since you may well need that page in order to bring it back in :-)
But that's a resident cost of only 32M of the 512M for the primary paging table, much better than the (at a minimum, for one fully-loaded process) of 736M.
size of the page table= total no of page table entries*size of the page table entry
STEP 1:FINDING THE NO OF ENTRIES IN PAGE TABLE:
no of page table entries=virtual address space/page size
=2^38/2^10=2^28
so there are 2^28 entries in the page table
STEP2:NO OF FRAMES IN PHYSICAL MEMORY:
no of frames in the physical memory=(512*1024*1024)/(1*1024)=524288=2^19
so we need 19 bits and additional 4 bits for valid, protection, dirty and use bits
totally 23 bits=2.875 bytes
size of the page table=(2^28)*2.875=771751936B=736MB
1KB pages = 2^10, 512MB = 2^29 => Offset = 29 - 10 = 19 bit.
virtual includes two part: page frame + offset => page frame + dirty bit = 38 - 19 = 29 bit.
29 bit includes 4 bit dirty (above) => 25 bit for real page frame, each page frame has 10 bit long.
So, page table size: 2^25 * 10 = 320M.
Hope this correct.