Day13 demand page 与 copy on write

前言

前面介绍了记忆体分页的管理机制,分页管理让记忆体管理不再以行程为管理的单位,而是以页为单位作为记忆体管理的基本单位,虚拟记忆体是一个能映射到实体记忆体与硬碟的储存区域,CPU会产生一个虚拟位址,并且经过查询每个行程个别的记忆体映射表(memory mapping table),进而能够找到该部分的资料在记忆体中,或是其他的储存区域里,如果是在硬碟里则将资料移动到记忆体中。将这两个技术合并,就变成分页的虚拟记忆体,便是现今最常出现的应用方式,今天要讲讲因为以分页虚拟记忆体机制为基底而产生的两个技术,分别是需求分页 (demand page)与 写入时复制(copy on write)。

demand page

Cow (copy on write)

from wiki

如果有多个呼叫者(callers)同时请求相同资源(如记忆体或磁碟上的资料储存),他们会共同取得相同的指标指向相同的资源,直到某个呼叫者试图修改资源的内容时,系统才会真正复制一份专用副本(private copy)给该呼叫者,而其他呼叫者所见到的最初的资源仍然保持不变。这过程对其他的呼叫者都是透明的。此作法主要的优点是如果呼叫者没有修改该资源,就不会有副本(private copy)被建立,因此多个呼叫者只是读取操作时可以共享同一份资源。

当父行程 fork()一个子行程之後,子行程并没有马上复制父行程的资料,而是暂时与父行程共用,在自己的page table上标示这部分的资料只读不写,直到某一方要修改其中的资料的时候,会引发分页错误, do_wp_page()函数会处理那些行程试图修改、标示为只读的页面,重新分配记忆体页面并且复制就的页面内容到新的页面中。


<<:  Day 13:第三方套件、授权

>>:  [Day13] 以神经网络进行时间序列预测 — GRU

[Day29] 第二十九课 Azure灾害复原(DRaaS)-2[进阶]

我们来接续昨日Azure Site Recovery(ASR)的进度之前, 我想补充一下地端及云端容...

Day22 URLSession 02 - GET

GET:取资料 同样根据以上的Reqres API 来示范 首先一样根据Response 建立Mod...

.NET Core第18天_InputTagHelper的使用

InputTagHelper: 是针对原生HTML 的封装 新增InputController.cs...

Fluentd Bit

在 Fluentd Bit 中可以使用 read 或 socket 方式处理日志 read 用於读容...

Day11 X Lazy Loading

还记得昨天 Virtualized List 篇章开头放的 Facebook demo 影片吗?有...