Skip to content

Commit

Permalink
deploy: de8b320
Browse files Browse the repository at this point in the history
  • Loading branch information
wyfcyx committed Oct 15, 2024
1 parent f6a18d8 commit b961088
Show file tree
Hide file tree
Showing 3 changed files with 3 additions and 3 deletions.
2 changes: 1 addition & 1 deletion _sources/chapter4/3sv39-implementation-1.rst.txt
Original file line number Diff line number Diff line change
Expand Up @@ -334,7 +334,7 @@ SV39 多级页表的硬件机制

在 SV39 中,如果使用了一级页索引就停下来,则它可以涵盖虚拟页号的高 :math:`9` 位为某一固定值的所有虚拟地址,对应于一个 :math:`1\text{GiB}` 的大页;如果使用了二级页索引就停下来,则它可以涵盖虚拟页号的高 :math:`18` 位为某一固定值的所有虚拟地址,对应于一个 :math:`2\text{MiB}` 的大页。以同样的视角,如果使用了所有三级页索引才停下来,它可以涵盖虚拟页号的高 :math:`27` 位为某一个固定值的所有虚拟地址,自然也就对应于一个大小为 :math:`4\text{KiB}` 的虚拟页面。

使用大页的优点在于,当地址空间的大块连续区域的访问权限均相同的时候,可以直接映射一个大页,从时间上避免了大量页表项的读写开销,从空间上降低了所需节点的数目。但是,从内存分配算法的角度,这需要内核支持从物理内存上分配三种不同大小的连续区域( :math:`4\text{KiB}` 或是另外两种大页),便不能使用更为简单的插槽式管理。权衡利弊之后,本书全程只会以 :math:`4\text{KiB}` 为单位进行页表映射而不会使用大页特性。
使用大页的优点在于,当地址空间的大块连续区域的访问权限均相同的时候,可以直接映射一个大页,从时间上避免了大量页表项的读写开销,从空间上降低了所需页表节点的数目。更为重要的是,使用大页可以显著减轻 TLB 的压力,提升 TLB 命中率,因为现在 TLB 中一个表项可以覆盖更大的内存空间了。这可以从整体上提高访存指令的执行速度,进而提升整体的 IPC 。但是,从内存分配算法的角度,这需要内核支持从物理内存上分配三种不同大小的连续区域( :math:`4\text{KiB}` 或是另外两种大页),便不能使用更为简单的插槽式管理。权衡利弊之后,本书全程只会以 :math:`4\text{KiB}` 为单位进行页表映射而不会使用大页特性。

那么 SV39 多级页表相比线性表到底能节省多少内存呢?这里直接给出结论:设某个应用地址空间实际用到的区域总大小为 :math:`S` 字节,则地址空间对应的多级页表消耗内存为 :math:`\frac{S}{512}` 左右。下面给出了详细分析,对此不感兴趣的同学可以直接跳过。

Expand Down
2 changes: 1 addition & 1 deletion chapter4/3sv39-implementation-1.html
Original file line number Diff line number Diff line change
Expand Up @@ -631,7 +631,7 @@ <h2>多级页表<a class="headerlink" href="#id6" title="永久链接至标题">
<p>RISC-V 64处理器在地址转换过程中,只要表项中的 <code class="docutils literal notranslate"><span class="pre">V</span></code> 为 1 且 <code class="docutils literal notranslate"><span class="pre">R/W/X</span></code> 不全为 0 就会直接从当前的页表项中取出物理页号,再接上页内偏移,就完成最终的地址转换。注意这个过程可以发生在多级页表的任意一级。如果这一过程并没有发生在多级页表的最深层,那么在地址转换的时候,物理页号对应的物理页帧的起始物理地址的位数与页内偏移的位数都和按缺省页处理时的情况不同了。我们需要按 <strong>大页</strong> 的地址转换方式来处理。</p>
<p>这里需要进一步理解将物理页号和页内偏移“接起来”这一行为,它的本质是将物理页号对应的物理页帧的起始物理地址和页内偏移进行求和,物理页帧的起始物理地址是将物理页号左移上页内偏移的位数得到,因此看上去恰好就是将物理页号和页内偏移接在一起。如果在从多级页表往下走的中途停止,未用到的页索引会和虚拟地址的 <span class="math notranslate nohighlight">\(12\)</span> 位缺省页内偏移一起形成一个位数更多的 <strong>大页</strong> 页内偏移。即对应于一个大页,在转换物理地址的时候,其算法仍是上述二者求和,只是物理页帧的起始物理地址和页内偏移的位数不同了。</p>
<p>在 SV39 中,如果使用了一级页索引就停下来,则它可以涵盖虚拟页号的高 <span class="math notranslate nohighlight">\(9\)</span> 位为某一固定值的所有虚拟地址,对应于一个 <span class="math notranslate nohighlight">\(1\text{GiB}\)</span> 的大页;如果使用了二级页索引就停下来,则它可以涵盖虚拟页号的高 <span class="math notranslate nohighlight">\(18\)</span> 位为某一固定值的所有虚拟地址,对应于一个 <span class="math notranslate nohighlight">\(2\text{MiB}\)</span> 的大页。以同样的视角,如果使用了所有三级页索引才停下来,它可以涵盖虚拟页号的高 <span class="math notranslate nohighlight">\(27\)</span> 位为某一个固定值的所有虚拟地址,自然也就对应于一个大小为 <span class="math notranslate nohighlight">\(4\text{KiB}\)</span> 的虚拟页面。</p>
<p>使用大页的优点在于,当地址空间的大块连续区域的访问权限均相同的时候,可以直接映射一个大页,从时间上避免了大量页表项的读写开销,从空间上降低了所需节点的数目。但是,从内存分配算法的角度,这需要内核支持从物理内存上分配三种不同大小的连续区域( <span class="math notranslate nohighlight">\(4\text{KiB}\)</span> 或是另外两种大页),便不能使用更为简单的插槽式管理。权衡利弊之后,本书全程只会以 <span class="math notranslate nohighlight">\(4\text{KiB}\)</span> 为单位进行页表映射而不会使用大页特性。</p>
<p>使用大页的优点在于,当地址空间的大块连续区域的访问权限均相同的时候,可以直接映射一个大页,从时间上避免了大量页表项的读写开销,从空间上降低了所需页表节点的数目。更为重要的是,使用大页可以显著减轻 TLB 的压力,提升 TLB 命中率,因为现在 TLB 中一个表项可以覆盖更大的内存空间了。这可以从整体上提高访存指令的执行速度,进而提升整体的 IPC 。但是,从内存分配算法的角度,这需要内核支持从物理内存上分配三种不同大小的连续区域( <span class="math notranslate nohighlight">\(4\text{KiB}\)</span> 或是另外两种大页),便不能使用更为简单的插槽式管理。权衡利弊之后,本书全程只会以 <span class="math notranslate nohighlight">\(4\text{KiB}\)</span> 为单位进行页表映射而不会使用大页特性。</p>
</div>
<p>那么 SV39 多级页表相比线性表到底能节省多少内存呢?这里直接给出结论:设某个应用地址空间实际用到的区域总大小为 <span class="math notranslate nohighlight">\(S\)</span> 字节,则地址空间对应的多级页表消耗内存为 <span class="math notranslate nohighlight">\(\frac{S}{512}\)</span> 左右。下面给出了详细分析,对此不感兴趣的同学可以直接跳过。</p>
<div class="admonition note">
Expand Down
2 changes: 1 addition & 1 deletion searchindex.js

Large diffs are not rendered by default.

0 comments on commit b961088

Please sign in to comment.