精髓——高度概括几种页框到线性地址的映射技术

第一种:就是页框到线性地址的一 一映射关系。这是在分页阶段,已经建立好的(这部分我可以深入讲一下,但是这部分内容不是很难,而且我的肩膀好酸痛,就不写了,以后在补上),就是为物理内存前896M的每个页框建立页表,并写进页表项。当进程请求这部分内存时,可以直接访问到这些页表,而不并现场创建页表。

第二种:高端内存永久内核映射。就是上一篇博文讲到的。这种技术的映射可以阻塞进程,使进程去睡眠。

第三种:临时内核映射。其实道理差不多。任何一个页框与权限合成的页表可以写进预留的几个页表项中,但这种技术是不能阻塞的内核映射技术,因此可以用到中断处理函数和可延迟函数中。

第四种:非连续内存映射技术。用slab分配器分配线性区描述符,然后在非连续内存区找到一块空闲的线性区。然后把申请到的每一个零散的物理页框描述符和权限合成页表,并将此页表写到查找到的线性区对应的页表项中。(其实道理都是差不多的,只要领悟了上一篇博文写的永久内核映射思想,那么此种技术的思想也是一样的:查找物理页框,(合成页表,写进页表项,返回线性地址)

后3种技术会重写页表,导致tlb中的页表无效。

大道至简,只要记住以下几句话那么面对各种映射技术就不会恐慌:

查找页框,合成页表,写进页表项,返回页表项的线性地址

以后几篇的更新会涉及物理内存页框的分配。内核的映射就写到这里

时间: 2024-10-13 00:21:30

精髓——高度概括几种页框到线性地址的映射技术的相关文章

Linux内核剖析 之 回收页框

一.页框回收算法 1.为何要有页框回收算法? Linux在为用户态与内核分配动态内存时,检查得并不严谨. 例如: (1).对单个用户创建的进程的RAM使用的总量并不作严格的检查(进程资源的限制只针对单个进程): (2).对内核使用的许多磁盘高速缓存和内存高速缓存大小也同样不做限制. 2.为何要减少控制? 可以使内核以最好的可行方式使用可用的RAM: (1).当系统负载较低时,RAM的大部分由磁盘高速缓存占用,较少的正在运行的进程可以获益: (2).当系统负载增加时,RAM的大部分则由进程页占用,

深入理解Linux内核-回收页框

Linux 系统在为用户态进程和内核分配动态内存的时候,所作的检查是马马虎虎的对内核使用的许多磁盘高速缓存和内存高速缓存大小也同样不作限制. 页框回收算法(PFRA):1.在所有内存使用完之前,就必须执行页框回收算法2.选择目标页,它获取页框,并且使之空闲3.候选回收页:任何属于磁盘和内存高速缓存的页,以及属于进程用户态地址空间的页4.首先释放‘无害’页:先释放没有被任何进程使用的磁盘与内存高速缓存中的页5.将用户态进程的所有页定为可回收页.6.同时取消引用一个共享页框的所有页表项的映射,就可以

per-CPU分配和释放单页框

内核经常请求和释放单个页框.为了提升系统性能,每个内存管理区定义了一个"每CPU"页框高速缓存.所有"每CPU"高速缓存包含一些预先分配的页框,它们被用于满足本地CPU发出的单一内存请求. 为每个内存管理区和每CPU提供了两个高速缓存:一个热高速缓存,它存放页框中所包含的内容很可能就在CPU硬件高速缓存中:还有一个冷高速缓存. 在内存管理区中,分配单页使用per-cpu机制,分配多页使用伙伴算法,结构图如下: 1.相关结构体 zone结构体中pageset成员指向内

【iOS开发-56】案例BUG:按钮的enabled、控件的userInteractionEnabled以及两种提示框UIAlert和UIActionSheet

接上述案例找BUG:[iOS开发-51]案例学习:动画新写法.删除子视图.视图顺序.延迟方法.按钮多功能用法及icon图标和启动页设置 (1)BUG:答案满了就不能再点击option按钮,答案没满就能点. 在optionClick方法的if(full)中设置,即判断答案是否满了,如果满了,则: if (full) { //如果答案满了,不管是否正确,只要满了,下面的option按钮就不能被点击 for (UIButton *optionBtn in self.optionView.subview

【iOS开发-56】案例BUG:button的enabled、控件的userInteractionEnabled以及两种提示框UIAlert和UIActionSheet

接上述案例找BUG:[iOS开发-51]案例学习:动画新写法.删除子视图.视图顺序.延迟方法.button多功能使用方法及icon图标和启动页设置 (1)BUG:答案满了就不能再点击optionbutton,答案没满就能点. 在optionClick方法的if(full)中设置,即推断答案是否满了,假设满了.则: if (full) { //假设答案满了,无论是否正确,仅仅要满了,以下的optionbutton就不能被点击 for (UIButton *optionBtn in self.opt

操作系统内存管理之 分页与虚存(页表、页框、内存)

一 页面与页表 1 页面 分页存储管理是将作业的逻辑地址划分为一系列同等大小的部分,称为页.并为各页加以编号,每个作业的页的编号都是从0开始的.与之类似,把可用的物理内存也划分为同样大小的连续的部分,称为块或页框.同样为块也进行标号,从0#开始.在为进程分配内存空间时,以页为单位,每个内存中的块存放一页用户作业.只要内存中有足够多的块,这些块可以相邻也可以不相邻,就可以存放整个作业了. 页面的大小对于内存利用和系统开销来说非常重要,页面太大,在作业的最后一页必然会剩余较大不能利用的空间--内碎片

高度概括

唯一真正对FSFS不利的是相对于Berkeley DB的不成熟,缺乏足够的使用和压力测试,许多关于速度和可扩展性的判断都是建立在良好的猜测之上.在理论上,它承诺会降低管理员新手的门槛并且更加不容易发生问题.在实践中,只有时间可以证明. 总之,这两个中并没有一个是更正式的,访问版本库的程序与采用哪一种实现方式无关.通过上文和下表(从总体上比较了Berkeley DB和FSFS版本库),读者可以自行选择自己需要的存储方式 对计算机及其相关硬件非常了解(包括但不限于pc机,服务器,小型机,存储器,交换

linux内存源码分析 - 伙伴系统(初始化和申请页框)

本文为原创,转载请注明:http://www.cnblogs.com/tolimit/ 之前的文章已经介绍了伙伴系统,这篇我们主要看看源码中是如何初始化伙伴系统.从伙伴系统中分配页框,返回页框于伙伴系统中的. 我们知道,每个管理区都有自己的伙伴系统管理属于这个管理区的页框,这也说明了,在伙伴系统初始化时,管理区必须要已经存在(初始化完成)了.在管理区描述符(struct zone)中,struct free_area就专门用于描述伙伴系统的.在一个管理区中,伙伴系统一共维护着包含1,2,4,8,

JS的三种消息框

第一种:警告框 : alert("文本") 例子:alert("警告"); 第二种 : 确认框: confirm("文本") 例子:confirm("确认"); 第三种:提示框:prompt("文本",“默认值”) 例子:prompt("请输入姓名","gangqing")