Chinaunix

标题: 虚拟内存的意义?对硬件有什么要求? [打印本页]

作者: 雨丝风片    时间: 2006-03-21 08:35
标题: 虚拟内存的意义?对硬件有什么要求?
这是【FreeBSD操作系统设计与实现】的习题5.1,原文如下:

5.1 What does it mean for a machine to support virtual memory? What four hardware facilities are typically required for a machine to support virtual memory?
作者: gvim    时间: 2006-03-21 09:19
这部分我还没有看,先看看我回答的和老大们讲的有什么差别

What does it mean for a machine to support virtual memory?
进程保护,虚拟大空间支持,权限检查,多进程支持  我想出来4个。

four hardware facilities
虚拟和实地址的转换、映射设备,大容量后备存储器  想出来2个。
作者: 雨丝风片    时间: 2006-03-21 09:43
这是俺从书上总结的答案(有点像答政治题)

虚拟内存的意义:
1、“穷庙富和尚”,主存小的机器也可以运行超过主存容量的大程序。
2、“给点阳光就灿烂”,程序可以更快启动,不必把自己整个都塞到主存中。
3、“海阔凭鱼跃,天高任鸟飞”,程序员对于地址空间的使用更为自由,不必再斤斤计较了。

对硬件的要求:
1、能够防止程序改变它们自己的地址映射。
2、能够区分地址空间中的驻留部分和未驻留部分,程序访问未驻留部分时即挂起,所需内容放到内存中之后即恢复。
3、能够保存机器状态以恢复指令执行。
4、能够采集程序对内存的引用信息。
作者: albcamus    时间: 2006-03-21 11:14
CPU对虚存的支持主要是其分页单元吧? 还有MMU和TLB, 感觉断点恢复什么的与虚存不是很有关系
作者: gvim    时间: 2006-03-21 11:45
原帖由 albcamus 于 2006-3-21 11:14 发表
CPU对虚存的支持主要是其分页单元吧? 还有MMU和TLB, 感觉断点恢复什么的与虚存不是很有关系


我觉得对虚拟内存的支持来说,TLB可有可无,它的存在是考虑效率。
作者: 雨丝风片    时间: 2006-03-21 11:52
原帖由 albcamus 于 2006-3-21 11:14 发表
CPU对虚存的支持主要是其分页单元吧? 还有MMU和TLB, 感觉断点恢复什么的与虚存不是很有关系


我感觉这本书主要侧重于偏“软”一点的虚存系统的数据组织和相关算法,对于实际的地址映射过程却不太关心,不像《Linux内核源代码情景分析》那样。

此处的第三点断点恢复主要是和第二点关联起来说的,作者的意思是当一个进程引用了一个目前不在主存中的页面的时候,就需要把这个进程挂起,在把所请求的页面调进主存之后再恢复进程的运行,所以才把这个“断点恢复”的能力也列为了一条。
作者: colddawn    时间: 2006-03-21 12:21
以I686为例,上面老大所列举的几点有哪些是cpu硬件实现?哪些是操作系统实现的?
作者: 雨丝风片    时间: 2006-03-21 12:43
原帖由 albcamus 于 2006-3-21 11:14 发表
CPU对虚存的支持主要是其分页单元吧? 还有MMU和TLB


我是从书中专门讲硬件要求的一节中摘出来的,所有就有了遗漏,

albcamus老大说的分页单元和MMU都是虚拟内存的根本,我前面列出的只能算是一些“额外”的要求,
作者: colddawn    时间: 2006-03-21 13:47
记得内存管理在IA架构上有个从实模式到保护模式的历史过程,而页式管理也不是一开始就有的,寻址方式也有个从段式逻辑地址到线性地址再到页式地址的过程,不知道有没有大虾能结合历史原因讲解一下这些方式在历史上的变迁和其不同时期的特点和作用,能加强一下理解,本人对于存储管理这方面是基本上处于不很懂得状态。

另问下,对于i386-i686页大小都是固定4kb吗?有没有方法改变?X86_64和EM64T呢?
作者: albcamus    时间: 2006-03-21 14:28
原帖由 colddawn 于 2006-3-21 13:47 发表
记得内存管理在IA架构上有个从实模式到保护模式的历史过程,而页式管理也不是一开始就有的,寻址方式也有个从段式逻辑地址到线性地址再到页式地址的过程,不知道有没有大虾能结合历史原因讲解一下这些方式在历史上 ...


这个恐怕谁都不敢讲不愿讲……太复杂啦

IA32从某个开始, 支持PSE, 4M的大页面。 应该是写cr0或者其他的控制寄存器的某个标志置1就生效的, 具体记不清楚。 EM64T技术, BSD支持的怎么样? 官方Linux内核的支持不清楚, 只知道Novell版支持。

P.S. 雨丝风片版主别对偶们小朋友那么客气,偶会折寿的说
作者: colddawn    时间: 2006-03-21 14:32
原帖由 albcamus 于 2006-3-21 14:28 发表


这个恐怕谁都不敢讲不愿讲……太复杂啦

IA32从某个开始, 支持PSE, 4M的大页面。 应该是写cr0或者其他的控制寄存器的某个标志置1就生效的, 具体记不清楚。 EM64T技术, BSD支持的怎么样? 官方Linux内 ...


FB有X86_64的官方版本,EM64T不知道。RedHat Linux也有,奇怪的是Redhat的X86_64和EM64T是一个版本的,难道说AMD和Intel搞出来的东西完全一样的?

我对内存管理现在还停留在实模式下的水平,当年dos game玩多了搞得,保护模式一窍不通,所以才问问看有没有大牛解惑。

[ 本帖最后由 colddawn 于 2006-3-21 14:38 编辑 ]
作者: 雨丝风片    时间: 2006-03-21 16:37
原帖由 colddawn 于 2006-3-21 13:47 发表
记得内存管理在IA架构上有个从实模式到保护模式的历史过程,而页式管理也不是一开始就有的,寻址方式也有个从段式逻辑地址到线性地址再到页式地址的过程,不知道有没有大虾能结合历史原因讲解一下这些方式在历史上 ...


我觉得《Linux内核源代码情景分析》的1.2节“Intel X86 CPU系列的寻址方式”可以在很大程度上满足你的考古兴趣!
作者: albcamus    时间: 2006-03-28 09:45
标题: 回复 11楼 colddawn 的帖子
我周末看了下IA32手册讲述EM64T的部分, 感觉跟AMD64就是一个体系结构, 至少从指令集上来看是兼容的。 比方都有16个64位通用寄存器, 都有flat内存模型, 等。 不同的是EM64T的物理总线宽度是40, 我还没看到AMD64的是多少,猜测是64.
作者: gvim    时间: 2006-03-28 10:13
我所知道的intel 64最大的改进是使用了VLIW,据说还是intel china的人搞出来的。
不过编译器还不能很好的达到要求,所以EPIC推广比较不顺利。EM64和AMD64的我不清楚。
作者: gvim    时间: 2006-03-28 10:41
有了,娃哈哈哈哈哈,刚搜索了下emule,
Morgan Kaufmann - Embedded Computing. A VLIW Approach to Architecture, Compilers, and Tools (2005).pdf
还比较新。
作者: albcamus    时间: 2006-03-28 18:05
原帖由 gvim 于 2006-3-28 10:41 发表
有了,娃哈哈哈哈哈,刚搜索了下emule,
Morgan Kaufmann - Embedded Computing. A VLIW Approach to Architecture, Compilers, and Tools (2005).pdf
还比较新。


我看的ia64那本书说, VLIW做不到二进制兼容, 后续实现不兼容老的实现, 是这样吗? 如果是这样, 那除了科学计算和国防之类的场合, 没人敢用啊
作者: gvim    时间: 2006-03-28 18:19
原帖由 albcamus 于 2006-3-28 18:05 发表


我看的ia64那本书说, VLIW做不到二进制兼容, 后续实现不兼容老的实现, 是这样吗? 如果是这样, 那除了科学计算和国防之类的场合, 没人敢用啊


可以用在很多处理器里面阿,比如GPU,比如网络处理器,等等。我觉得VLIW用在通用处理器里面,先不考虑兼容性,相比 multi-core/multi-processor 这样的多执行绪的结构,首先编译器的构造要困难很多,再次,处理器前端复杂(指令长度可变,前端复杂性从CISC和RISC的比较就可见一斑),最后效率上讲,还没有看到相关评测,也就很难说它和其他的流行parallel architecture相比,到底效率如何。不过这个东西还比较前卫,应该也是一种非通用处理器的一种构架选择。

[ 本帖最后由 gvim 于 2006-3-28 18:21 编辑 ]
作者: 雨丝风片    时间: 2006-03-28 19:12
两位老大玩得太深奥了,看不懂啊。。。




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2