【问题标题】:Number of memory access with Demand Paging请求分页的内存访问次数
【发布时间】:2018-12-01 14:58:20
【问题描述】:

我一直在研究操作系统概念,我所指的书是 Peter B. Galvin、Greg Gagne 和 Abraham Silberschatz 的操作系统概念。

在虚拟内存一章中,本书开始讨论分页和内存访问次数,系统在给定逻辑地址的情况下读取存储在内存中特定帧中的数据。作者指出,当主内存中存在页表时,系统需要两次内存访问才能读取存储在帧中的数据。第一次访问页表以读取正确的帧号,下一次访问是从帧中读取字节/字。

在几节之后,本书讨论了需求分页和页面错误。作者指出,在没有缺页的情况下,需要一次内存访问,在缺页的情况下,我们将考虑缺页服务时间(包括交换时间、换出时间、一次内存访问等)并提出有公式的读者

有效访问时间 = (1-p) x 1 个内存访问时间 + p x 缺页服务时间

其中 p = 页面错误率

我无法理解为什么作者建议在没有页面错误的情况下只需要一次内存访问。应用同一作者之前介绍的标准分页方案的思路,我们应该需要一个内存访问来读取页表,另一个来从帧中读取数据。

是因为我们在讨论访问页表后的时间范围吗?那为什么同样的计算标准不适用于标准版的分页呢?

【问题讨论】:

    标签: operating-system paging memory-access demand-paging


    【解决方案1】:

    注意:我没有读过/看过这本书。

    用于教育材料;如果作者用所有细节准确地描述现实,读者只会感到困惑,无法学习。为了解决这个问题,作者在引入不同概念的同时简化(省略细节并忽略现实),以便读者能够一次学习每个概念,同时积累理解现实复杂性所需的知识。

    问题在于,不同的简化在不同的阶段有意义,而且作者是人(不完美),所以有时在某一时刻(在一章中)有益的简化与在以后的某个时刻有益的简化(在不同的章节)。

    例如,我可能(最初)告诉某人“每次从虚拟内存访问都涉及从 RAM 中获取第二次内存以确定转换”,以帮助他们了解页表的工作原理以及涉及的(潜在)性能问题(两倍的内存访问)。然后我可能会介绍“翻译后备缓冲区”的概念(在读者了解页表的工作原理并了解 TLB 旨在解决的问题之后)。然后我可能会解释说,实际系统通常有多个级别的页表(例如,在 64 位 80x86 上它是四个级别,可能涉及 4 次内存访问以确定翻译)并且可能涉及更高级别的缓存/缓冲区(而不仅仅是缓存最终翻译的 TLB)。在这种情况下,我最初的陈述(“每次从虚拟内存访问都涉及从 RAM 中提取第二次内存以确定翻译”)是故意撒谎(简化)以避免像“每次从虚拟内存访问可能或者可能不涉及从某些或所有级别的页表中进行一个或多个额外的提取”(这对初学者来说太混乱了,因为它会产生很多他们还没有答案的问题)。

    我无法理解为什么作者建议在没有页面错误的情况下只需要一次内存访问。

    一个现实是(对于一个真正的 80x86 CPU 处于长模式,但不是所有 80x86 CPU 处于长模式,而不是任何 80x86 处于其他模式,如果没有使用虚拟化),从虚拟内存读取不会导致页面错误,如果访问没有错位/跨页面边界拆分(CPU 必须全部执行两次才能从 2 个不同的页面获取字节并合并字节):

        * if the translation is not in the TLB, then:
            * if the area is not in the "page directory cache"
                * fetch the PML4 entry to determine address of PDPT (try L1 cache, then L2 cache, then L3 cache, then RAM)
                * do access checks based on flags in PML4 entry
                * fetch the PDPT entry to determine address of PD (try L1 cache, then L2 cache, then L3 cache, then RAM)
                * do access checks based on flags in PDPT entry
                * insert data into "page directory cache"
            * if the area is in the "page directory cache"
                * do access checks based on flags in "page directory cache entry"
            * fetch the PD entry to determine address of PT (try L1 cache, then L2 cache, then L3 cache, then RAM)
            * do access checks based on flags in PD entry
            * fetch the PT entry to determine address of page (try L1 cache, then L2 cache, then L3 cache, then RAM)
            * do access checks based on flags in PT entry
            * insert data into TLB (including setting the "accessed" flag in the page table entry)
        * if the translation is in the TLB, then:
            * do access checks based on flags in "TLB entry"
        * do the "physical address = physical address of page + offset in page" calculation
        * read the data for the physical address (try L1 cache, then L2 cache, then L3 cache, then RAM)
    

    对于这个现实(有提到的限制);从 RAM 中提取的次数可以是 0 到 5 之间的任意值。

    你能明白为什么作者(在试图解释页面错误而不是试图解释翻译成本时)可能希望避免显示这样的内容并可能会简化(假设只需要一次提取,因为翻译在TLB) 代替?

    【讨论】:

    • 是的。确实,我这样做了,这是我最初的倾向之一。这个想法是有几个复杂性可能会使深入研究可能需要的确切内存读取次数变得乏味。明白了。
    【解决方案2】:

    您的问题的根本根源在于您正在阅读一本只适合衬在猫箱上的书。您所描述的是教科书用来在学生之间造成混乱的荒谬胡言乱语。这不是过度简化的情况,因为作者显然为访问时间抛出了一个荒谬的公式。

    这样的公式

    有效访问时间 = (1-p) x 1 个内存访问时间 + p x 缺页服务时间

    是没有现实依据的总牛粪废物。

    作者指出,当主内存中存在页表时,系统需要两次内存访问才能读取存储在帧中的数据。

    处理器必须使用页表将逻辑地址转换为物理地址。假设 CPU 中没有缓存,那么 CPU 已经读取了每次内存访问的页表。

    读取的次数取决于 CPU 使用的页表格式。

    假设您的进程有一个多级页表。在这种情况下,CPU 必须对表的每个级别进行读取。

    如果您的 CPU 具有单独的线性系统页表和用户页表,并且用户表位于逻辑地址中,则每次访问系统空间都需要读取一次内存,每次访问用户空间至少需要两次内存访问,并且实际上,可能会触发页面错误。第一次读取是到系统页表中查找用户页表项。第二次读取的是用户页表。三是数据。

    实际上,地球上的每个 CPU 都会进行页表缓存,因此不需要(一直)单独读取。

    我无法理解为什么作者建议在没有页面错误的情况下只需要一次内存访问。

    听起来这本书的 BS 不一致。

    现实情况是,逻辑记忆翻译需要多个步骤。然而,这些步骤是什么取决于处理器的状态,这是不可预测的。这些步骤在幕后透明地进行,您甚至无需掌握所有步骤即可了解操作系统。

    在现实世界中您需要知道的是 CPU 将逻辑地址转换为物理地址。如果 CPU 无法进行该转换,则会触发页面错误。

    【讨论】:

    • 确实,教科书被这种简化/公式化的尝试所破坏,反而造成了一些混乱。将尝试解决这些公式,并尝试更多地关注基本原则。
    • 他们试图把简单的事情变得复杂,并试图产生[毫无意义的]章尾练习。
    猜你喜欢
    • 2013-03-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-06-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-08-27
    相关资源
    最近更新 更多