An Operating System uses a paging system with 4Kbyte pages. A given process uses a virtual address space of 8G and is assigned 4G of physical memory. How many entries does its page table contain?
Its page table needs 8 GiB / 4 KiB = 8 * 1024 * 1024 * 1024 / 4 / 1024 = 2 * 1024 * 1024 = 2097152 entries.
In that case; because there's 8 GiB of virtual space and only 4 GiB of physical memory; at least half of the page table entries must refer to something that isn't a unique page of physical RAM (e.g. some page table entries say their page isn't present, or some page table entries refer to the same physical RAM so that that same data appears in the virtual address space multiple times, or a mixture of both).
Related
The following parameters apply to a system employing a 40-bit virtual address and
1G bytes of physical (main) memory. Word size is 64 bits (8 bytes). Addresses point
to bytes and are aligned on byte boundaries. We use the following notation for an i-bit
address: Ai-1...A2,A1,A0 where Ai-1 is the most significant bit of the address and A0
is the least significant bit of the address. The virtual address is denoted by V39-V0
and the physical address is denoted by P29-P0.
Page size: 64 K bytes
Page table: three-level page table
The virtual page number is split in 3 fields of 8 bits each.
Entries in all tables are 32 bits (4 bytes).
This is what I have found so far,
Since it is a 40 bit virtual address and the Page Size is 64kB (2^16), 16 bits are for offset and we subtract 16 from 40. The remaining 24 bits are for the Virtual Page Number (VPN). The VPN is split in 3 fields of 8 bits each. So we have a three level page table. Each table has 2^8 entries and the size of each table is 2^8 * 4 bytes = 1024 bytes.
From here how would we proceed and find the total amount of virtual memory covered by one entry of page tables at each level?
At the lowest level each entry points to a single page, so working out the amount of virtual memory is trivial, its the size of 1 page. At each of the higher level, one entry represents n entries in the lower table (2^8 in this case). So for the second level its n * amount covered by a bottom level entry, or 2^8* the size of a page. Then use the size of a second level to repeat this calculation for the third level.
When processes are allowed to grow larger than memory, page tables also grow very large. How could we organize page tables and TLB to keep access times as quick as possible for codes with good locality? For example, assume physical memory is 512K, each page is 1K, and a TLB of size 128. If we assume most processes are 256K or less, then we could allocate a fixed-size page table with 256 entries. Now in the unexpected case, where the page table grows larger than 256 entries, how should we organize it? What implications does your design have on average access time and on the maximum virtual memory size of a program?
The solution used on x86 is to have "sparse" page tables, that is there isn't a full table to contain a mapping for each page. Rather a two level mechanism is used:
The virtual memory is 4 GB large. A single page has size 4 KB. Using a one level approach would thus require a table of 4 GB / 4 KB = 1024 * 1024 entries. If an entry consumed 4 bytes, then every process would need 4 MB just to store its table.
Using a two level approach we have a page directory with 1024 entries, each of size 4 bytes (making it fit perfectly into a single 4 KB page). Thus each entry in that directory manages 4 GB / 1024 = 4 MB. If (and only if) there should be a mapping of some pages of virtual memory to physical memory in that 4 MB range, then the entry points to an instance of another structure, a page table. That contains 1024 entries, too, so each one manages 4 MB / 1024 = 4 KB exactly one page.
If there's a process that just needs a single page to operate, then using the single level approach we need 4 MB to store its virtual memory configuration. Using the two level mechanism described above, we need 4 KB for the page directory and 4 KB for the page table containing the mapping for that single page. Thus only 8 KB are used to store the virtual memory configuration.
If the process needs additional memory at runtime, and if that memory is at a (virtual) address not within the 4 MB range managed by its page table, then a second page table needs to be provided, increasing the memory used to store the mappings by another 4 KB.
Using this two level approach slightly increases access times for pages not in the TLB, because the memory management unit needs to access two memory locations (the page directory, and afterwards the respective page table) to be able to compute the physical address.
The TLB is unaffected by this: It stores mappings of single pages. How these mappings have been established isn't relevant to its operation.
Let's apply this to the example configuration you gave above:
A singe page has 1 KB size. Most processes, as you said, will have 256 KB or less memory. But we want to be able to have processes using more virtual memory.
If we choose to have the last level handle a full 256 KB, then we have
256 KB / 1 KB = 256 entries. Assuming a 32 bit architecture, this in turn means we can have each entry with size of 4 byte (to hold an address). 256 entries * 4 Byte = 1 KB and thus a full page. Nice.
To be able to handle more virtual memory than 256 KB we add another layer. Because it's easy, we let this level use tables with 256 entries (a 4 byte), too, to make such a table exactly fit into a page.
This gives us a virtual memory of 256 * 256 KB (roughly 65 MB). An virtual address in that system would then be 26 bit long:
DDDDDDDDTTTTTTTTPPPPPPPPPP
D := Index to page directory, highest level.
8 bit to be able to index 256 entries.
T := Index to page table, lower level.
8 bit to be able to index 256 entries.
P := Offset inside page.
10 bit to be able to address 1024 bytes.
A process using less than 256 KB needs then 2 KB to manage its memory configuration. Each additional 256 KB of virtual memory needed add another 1 KB of configuration memory.
Assuming the TLB can hold 128 entries (your question is a bit unclear here) it would need 128 * (16 + X - 10) bit, where X is the number of bits used to address physical memory. (Though this depends on the actual implemenation. I was thinking about16 bit per entry to store the indices of the paging structures + the upper bits of the physical address, not counting the 10 bits offset)
I hope this answers your question. An actual implementation will need to make design choices based on a lot of constraints.
What does this statement mean with respect to an operating system?
With a 2^32 address space and 4K ( 2^12 ) page sizes, this leave 2^20
entries in the page table. At 4 bytes per entry, this amounts to a 4
MB page table, which is too large to reasonably keep in contiguous
memory. ( And to swap in and out of memory with each process switch. )
Note that with 4K pages, this would take 1024 pages just to hold the
page table!
Please explain how they are calculating 1024 pages at the end? What is 4 bytes per entry in this regard? What is the meaning of 4K page size? Does 4K mean 4*1024 bytes? Are they considering 4 bytes (per word) OR does 4 bytes means it has 4*1024 words with each word having some size, say 4 bytes?
Please explain to me how they are calculating 1024 pages at the end?
Remember that we're dealing with powers of two, so
4 MB = 4,194,304 Bytes
4 KB = 4096 Bytes
4 MB / 4 KB = 4,194,304 Bytes / 4096 Bytes = 1024 Bytes
What is 4 Bytes per entry in this regard?
You need 32 bits to reference all 2^32 address spaces. With 8 bits per Byte, 32 bits = 4 Bytes.
For example the first address is 0 and the last address is 4294967295 or (2^32 - 1).
Entry | Page Memory Location
------------------------------------------
1 | 0
2 | 4096
3 | 8192
... | ...
2^20 | 4294963200 -> (2^32 - 1) - 4096
Each entry in the table points to 1 page somewhere out in memory. In this example lets say it starts at zero. There will be 2^20 entries and they will cover the entire span of memory addresses (2^32). Since each entry is 4096 Bytes you only need 2^20 entries to cover all of the pages.
4K means 4*1024 bytes?
Yes, it refers to each page being 4096 bytes (4*1024).
Are they considering 4 bytes (per word), OR 4 bytes means it has 4*1024 words which each word having some size say 4 bytes?
It can be smaller on 32 bit processors, but normally a word is 32 bits or 4 Bytes.
Additions Comments
When I say a page size is 4K, then it means it has 1024 entries with 4 bytes each or 1024*4 entries with 1 byte each or what else?
The page can hold anything, it's a container of data that is, in this example, 4096 Bytes. The page table holds entries that point to pages. As David stated, since the page table is stored in memory, it also is stored in pages.
Someone was saying that explanation is wrong. Correct one is: With a 2^32 address space and 4K (2^12) page sizes, this leave 2^20 pages in the table. At 4 bytes per entry, this amounts to a 4 GB page table, which is too large to reasonably keep in contiguous memory. (And to swap in and out of memory with each process switch.) Note that with 4K page sizes, this would take 1024 k pages (=1M pages) just to hold the total table! Is he correct or wrong?
He is incorrect. If the page table actually contained the data from each page then he would be correct. With 4096 byte pages and 2^20 entries, that would equal 4,294,967,296 bytes (4 GB), but the entries are only 4 bytes in size. So you multiple that with 2^20 entries to get 4,194,304 bytes (4 MB).
The documentation assumes these values:
2^32 = number of bytes in address space
2^12 = 4K = 4*1024 = number of bytes in one page
2^20 = 1M = 1024*1024 = number of pages
4 = number of bytes in the page table to describe one page
4M = 4*1024*1024 = total number of bytes in the page table
1024 = (4*1024*1024)/(4*1024) = number of pages in the page table
So 4 bytes is 4 bytes (the size of the entry in the page table for one page,
not the size of the page itself!).
Yes, 4K means 4*1024 bytes, not 4*1024 words.
All memory in use by the OS and any applications is stored in pages somewhere on the system.
Since the page table is something that has to be stored in memory, it also is stored in pages.
I found this example.
Consider a system with a 32-bit logical address space. If the page
size in such a system is 4 KB (2^12), then a page table may consist of
up to 1 million entries (2^32/2^12). Assuming that
each entry consists of 4 bytes, each process may need up to 4 MB of physical address space for the page table alone.
What is the meaning of each entry consists of 4 bytes and why each process may need up to 4 MB of physical address space for the page table?
A page table is a table of conversions from virtual to physical addresses that the OS uses to artificially increase the total amount of main memory available in a system.
Physical memory is the actual bits located at addresses in memory (DRAM), while virtual memory is where the OS "lies" to processes by telling them where it's at, in order to do things like allow for 2^64 bits of address space, despite the fact that 2^32 bits is the most RAM normally used. (2^32 bits is 4 gigabytes, so 2^64 is 16 gb.)
Most default page table sizes are 4096 kb for each process, but the number of page table entries can increase if the process needs more process space. Page table sizes can also initially be allocated smaller or larger amounts or memory, it's just that 4 kb is usually the best size for most processes.
Note that a page table is a table of page entries. Both can have different sizes, but page table sizes are most commonly 4096 kb or 4 mb and page table size is increased by adding more entries.
As for why a PTE(page table entry) is 4 bytes:
Several answers say it's because the address space is 32 bits and the PTE needs 32 bits to hold the address.
But a PTE doesn't contain the complete address of a byte, only the physical page number. The rest of the bits contain flags or are left unused. It need not be 4 bytes exactly.
1) Because 4 bytes (32 bits) is exactly the right amount of space to hold any address in a 32-bit address space.
2) Because 1 million entries of 4 bytes each makes 4MB.
Your first doubt is in the line, "Each entry in the Page Table Entry, also called PTE, consists of 4 bytes". To understand this, first let's discuss what does page table contain?", Answer will be PTEs. So,this 4 bytes is the size of each PTE which consist of virtual address, offset,( And maybe 1-2 other fields if are required/desired)
So, now you know what page table contains, you can easily calculate the memory space it will take, that is: Total no. of PTEs times the size of a PTE.
Which will be: 1m * 4 bytes= 4MB
Hope this clears your doubt. :)
The page table entry is the number number of bits required to get any frame number . for example if you have a physical memory with 2^32 frames , then you would need 32 bits to represent it. These 32 bits are stored in the page table in 4 bytes(32/8) .
Now, since the number of pages are 1 million i.e. so the total size of the page table =
page table entry*number of pages
=4b*1million
=4mb.
hence, 4mb would be required to store store the table in the main memory(physical memory).
So, the entry refers to page table entry (PTE). The data stored in each entry is the physical memory address (PFN). The underlying assumption here is the physical memory also uses a 32-bit address space. Therefore, PTE will be at least 4 bytes (4 * 8 = 32 bits).
In a 32-bit system with memory page size of 4KB (2^2 * 2^10 B), the maximum number of pages a process could have will be 2^(32-12) = 1M. Each process thinks it has access to all physical memory. In order to translate all 1M virtual memory addresses to physical memory addresses, a process may need to store 1 M PTEs, that is 4MB.
Honestly a bit new to this myself, but to keep things short it looks like 4MB comes from the fact that there are 1 million entries (each PTE stores a physical page number, assuming it exists); therefore, 1 million PTE's, which is 2^20 = 1MB. 1MB * 4 Bytes = 4MB, so each process will require that for their page tables.
size of a page table entry depends upon the number of frames in the physical memory, since this text is from "OPERATING SYSTEM CONCEPTS by GALVIN" it is assumed here that number of pages and frames are same, so assuming the same, we find the number of pages/frames which comes out to be 2^20, since page table only stores the frame number of the respective page, so each page table entry has to be of atleast 20 bits to map 2^20 frame numbers with pages, here 4 byte is taken i.e 32 bits, because they are using the upper limit, since page table not only stores the frame numbers, but it also stores additional bits for protection and security, for eg. valid and invalid bit is also stored in the page table, so to map pages with frames we need only 20 bits, the rest are extra bits to store protection and security information.
I'm looking over some exam papers for Operating Systems and I have come across a question which I simply cannot figure out. The memory management scheme is paging
Here is the question:
An operating system that runs on a CPU with a 16 bit address pointer employs a paging memory management scheme with a page size of 1024 bytes.
a) At most how many frames can physical memory contain?
b) Indicate which bits in an address pointer are used for page and offset.
c) A process image of size 3.5K resides in memory. You are given the page table of this process in Figure 1 below. What physical address will the hexadecimal logical address 0x0FCE result in? Show your calculations.
d) How much internal fragmentation does this process produce?
Page Frame
0 4
1 8
2 9
3 6
Figure 1 Process Page Table
Can anybody help me with this ?
A 16bit address bus allows to access 2^16 = 64kB of physical memory. Since on this system you have pages of size 1024B = 2^10, your memory falls into 2^16 / 2^10 = 2^6 physical frames.
Given the previous result, with pages of 1024 = 2^10 bytes, you need 10 bits for accessing any bytes of the page. Thus, the 6 high-order bits ares used for getting the page index from the page table (basically the figure 1 in your homework), and the 10 low-order bits are used for offsetting in that page.
The logical address 0xfce resides in the fourth page because the six high-order bits are 000011b = 3 = 4th page = 0x0c00-0x0fff. Given the page table and assuming the physical memory is sequential, the fourth page maps to the sixth physical frame which start at 1024 * 6 = 0x1800 = 0001100000000000b. The six high-order bits of the page are 000110b, where we add the 10 bits of offset resulting from the previous answer: 000110b << 10 | 0x3ce = 0x1bce.
Since the frame allocation is not sequential (4, 6, 8, 9), the hole between pages 4 and 6 (i.e. 1024B), and the hole between page 6 and 8(i.e. again 1024B), result in physical memory fragmentation.
Hope this help.