确定虚拟内存的页面表大小 [英] Determine page table size for virtual memory

问题描述

请考虑一个具有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.)

推荐答案

好吧，如果问题只是页面表的大小是多少?"不管它是否适合物理内存，都可以这样计算出答案:

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:

第一个物理内存.有512K页的物理内存(512M/1K).这需要19位来表示每个页面.将其添加到会计信息的4位中，您将获得23位.

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.

现在虚拟内存.具有38位地址空间和10位(1K)页面大小，在页面表中需要2 ²⁸ 条目.

Now virtual memory. With a 38-bit address space and a 10-bit (1K) page size, you need 2²⁸ entries in your page table.

因此，每个23位的2 ²⁸ 页表条目为6,174,015,488位或736M.

Therefore 2²⁸ page table entries at 23 bits each is 6,174,015,488 bits or 736M.

这是每个进程的单级VM子系统所需的最大大小.

That's the maximum size needed for a single-level VM subsystem for each process.

现在很明显，如果您只有512M的物理RAM，那么这是行不通的，因此有两种选择.

Now obviously that's not going to work if you only have 512M of physical RAM so you have a couple of options.

1. 您可以减少物理页面的数量.例如，只允许一半的内存进行分页，而另一半则始终保持不变.这将为每个条目节省一比特，不足以发挥作用.

1. 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.

增加页面大小，如果可能，增加 . 38位地址空间上的1K页是页面表非常矮的原因.例如，我认为带有其32位地址空间的'386使用4K页.这将导致一百万个页表项，远远少于此处所需的2.6亿.

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).

---

让我们更仔细地看一下选项3.

---

Let's look a little closer at option 3.

如果我们允许主分页表使用32M并为每个条目分配4个字节(32位:仅需要23个字节，但是我们可以在此处进行舍入以提高效率)，那么将为辅助分页表提供8,388,608页.

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.

由于每个辅助页面表页面的长度均为1K(允许我们以每个4个字节存储256个辅助页面表条目)，因此我们可以处理总共2147483483648个虚拟页面.

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.

假设您有相当大的磁盘空间来存储非驻留页面，那么这将允许8,192个满载(即，使用其全部的28位地址空间)进程并排运行.

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.

现在显然，主分页表(以及VM子系统，以及操作系统其余部分中的相当一部分)必须始终保持驻留状态.您可能不允许分页出其中一个主要页面，因为您很可能需要该页面才能将其带回:-)

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 :-)

但这仅是主要分页表的512M居民成本的32M，比736M的居民成本(最少，对于一个完全加载的过程而言)要好得多.

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.

这篇关于确定虚拟内存的页面表大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！