确定虚拟内存的页表大小
考虑一个具有 38 位虚拟字节地址、1KB 页和 512 MB 物理内存的虚拟内存系统。假设有效位、保护位、脏位和使用位总共占 4 位，并且所有虚拟页都在使用中，则本机上每个进程的页表总大小是多少？ （假设磁盘地址未存储在页表中。）
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.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，如果问题只是“页表的大小是多少？”不管它是否适合物理内存，答案都可以这样计算：
首先是物理内存。物理内存有 512K 页（512M / 1K）。这需要 19 位来表示每一页。将其添加到 4 位记帐信息中，您将得到 23 位。
现在虚拟内存。对于 38 位地址空间和 10 位 (1K) 页面大小，您的页表中需要 228 个条目。
因此，每个 23 位的 228 页表条目为 6,174,015,488 位或 736M。
这是每个进程的单级 VM 子系统所需的最大大小。
现在，如果您只有 512M 物理 RAM，显然这是行不通的，因此您有几个选择。
您可以减少物理页的数量。例如，只允许一半内存进行分页，而另一半则始终驻留。这将为每个条目节省一位，但实际上不足以产生影响。
如果可能的话，增加页面大小。。 38 位地址空间上的 1K 页是页表非常大的原因。例如，我认为具有 32 位地址空间的 '386 使用 4K 页。这将导致一百万个页表条目，远低于此处所需的 2.6 亿个。
多层次。更高级一点，但它基本上意味着页表本身要进行分页。您必须将第一级页表保留在物理内存中，但第二级页表可以根据需要进出。 但会以速度为代价，因为获取实际进程页面时可能会发生两级页面错误（一级用于辅助分页表，一级用于进程页面）。
让我们仔细看看选项 3。
如果我们允许主分页表为 32M，并给每个条目 4 个字节（32 位：只需要 23 位，但我们可以在这里四舍五入以提高效率），这将允许辅助分页表有 8,388,608 个页面页表。
由于每个辅助页表页都是 1K 长（允许我们以每个 4 字节存储 256 个辅助页表条目），因此我们总共可以寻址 2,147,483,648 个虚拟页。
这将允许 8,192 个完全加载（即使用其整个 28 位地址空间）进程并行运行，假设您有相当大的磁盘空间来存储非常驻页面。
现在显然主分页表（以及VM子系统，可能还有操作系统其余部分的相当一部分）必须始终保持驻留。不允许您调出其中一个主页面，因为您很可能需要该页面才能将其带回:-)
但是，主分页表的 512M 的驻留成本仅为 32M，比（至少，对于一个满载进程而言）736M。
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.
页表的大小=页表条目总数*页表条目的大小
第1步：查找页表中的条目数：
因此页表中有2^28个条目
第2步：物理内存中的帧数：
物理内存中的帧数=(512*1024*1024)/(1*1024)=524288=2^19，所以我们需要
19位和额外的< code>4 位 用于有效、保护、脏和使用位总共23位=2.875字节
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:
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^19so we need
19 bitsand additional4 bitsfor valid, protection, dirty and use bitstotally 23 bits=2.875 bytes