00000004.htm

一份很好的linux入门资料

&nbsp;<BR>
SVR4的VM&nbsp;Architecture源自於SunOS&nbsp;4.0引进的VM技术(Virtual&nbsp;<BR>
Memory之意).SunOS发展VM的用途在於提供memory&nbsp;sharing,&nbsp;<BR>
shared&nbsp;libraries,&nbsp;memory-mapped&nbsp;files.&nbsp;又因为SunOS可以在&nbsp;<BR>
M68K,&nbsp;I386,&nbsp;SPARC上执行,&nbsp;所以VM架构十分的portable.&nbsp;<BR>
&nbsp;<BR>
之後,&nbsp;在Sun和AT&amp;T合力之下,&nbsp;以VM为基础,&nbsp;设计了SVR4的virtual&nbsp;<BR>
memory系统.取代SVR3以前使用的regions架构.&nbsp;regions架构在Bach&nbsp;<BR>
的书上有提到.&nbsp;<BR>
&nbsp;<BR>
Memory-Mapped&nbsp;Files是透过virtual&nbsp;memory技术,&nbsp;把档案的内&nbsp;<BR>
容映到程式的定址空间,&nbsp;使得程式可以直接以存取记忆体的方&nbsp;<BR>
法存取档案.&nbsp;kernel提供了mmap()&nbsp;系统呼叫来作为此机制的介面.&nbsp;<BR>
&nbsp;<BR>
SVR4&nbsp;VM的设计概念,&nbsp;可以说是颠覆了传统对记忆体的观念.&nbsp;<BR>
在VM里面,physical&nbsp;memory变成是virtual&nbsp;address&nbsp;space的&nbsp;<BR>
cache而已.&nbsp;怎麽说呢?&nbsp;一个程式的位址空间可以被VM赋予不同&nbsp;<BR>
的意义,&nbsp;比如说某一段表示&nbsp;text,&nbsp;指向硬碟上可执行档的text区段,&nbsp;<BR>
某一段表示data,&nbsp;指向swap&nbsp;area,&nbsp;某段指向某个档案,&nbsp;为memory&nbsp;&nbsp;<BR>
mapped&nbsp;file的空间等等,&nbsp;VM的工作就是把这些实体的资料根据page&nbsp;<BR>
fault把他载入&quot;cache&quot;&nbsp;--&nbsp;主记忆体(以&nbsp;page&nbsp;为单位),好让cpu可以&nbsp;<BR>
存取.在主记忆体上的资料都是暂时的,&nbsp;他们都有个实体的贮存装置&nbsp;<BR>
作为长时间记录资料的地方.(这里的长时间指的是process&nbsp;block著,&nbsp;<BR>
sleep时,&nbsp;或者被swap&nbsp;out的意思).&nbsp;<BR>
&nbsp;<BR>
前一段提到data区段指向swap&nbsp;area是为了说明方便起见瞎掰的.&nbsp;真正的&nbsp;<BR>
作法是使用anonymous&nbsp;page来收容这些无家可归的小孩.&nbsp;data区段本来&nbsp;<BR>
指向档案,&nbsp;但是设下一个flag,&nbsp;只要一被修改,&nbsp;就变成&nbsp;anonymous&nbsp;page,&nbsp;<BR>
anonymous&nbsp;page就会自动使用swap&nbsp;area当作回存的装置.&nbsp;<BR>
&nbsp;<BR>
一个记忆体空间映到不同的东西,&nbsp;就应该有不同的程式来处理.&nbsp;SVR4把&nbsp;<BR>
一段空间称为一个segment.&nbsp;处理这种segment的程式就是segment&nbsp;driver.&nbsp;<BR>
本节并提到vnode和paging系统的相互作用.&nbsp;<BR>
&nbsp;<BR>
Solaris&nbsp;2.x对SVR4的改进为提出virtual&nbsp;swap&nbsp;space的方法,&nbsp;把&nbsp;<BR>
swap&nbsp;space扩展成swap&nbsp;area&nbsp;+&nbsp;physical&nbsp;memory&nbsp;(所以swap大小&nbsp;<BR>
可以小於physicalmem了?!)并且可以动态的重新分配swap区.&nbsp;之前&nbsp;<BR>
的作法是某块swap区只要配给哪个page,&nbsp;那整个process的生命周&nbsp;<BR>
期内,&nbsp;这块swap就是许配给这个process的特定page,不会再换了,&nbsp;<BR>
这样的缺点是不能动态的移除swap&nbsp;disk/file.为了达到这个&nbsp;<BR>
功效,&nbsp;Sloaris设计了swapfs,&nbsp;用来管理swap&nbsp;space.&nbsp;anonymous&nbsp;<BR>
page从此就回存到swapfs上,&nbsp;而不是直接pass过filesystem,&nbsp;<BR>
存到swap上了.&nbsp;<BR>
&nbsp;<BR>
当VM从SunOS移植到SVR4上时,&nbsp;效能和regions架构相比很不理想.&nbsp;经过&nbsp;<BR>
分析SVR4的fault&nbsp;rate太高了,&nbsp;所以可以作些改善.&nbsp;<BR>
&nbsp;<BR>
因为VM太懒了,&nbsp;所有的东西都是page&nbsp;fault之後再作,&nbsp;而page&nbsp;fault&nbsp;<BR>
的代价甚高.所以optimization朝向将一些显然会发生的page&nbsp;fault&nbsp;<BR>
减少.&nbsp;比如说在fork和exec中间一般程式都会做一些事,&nbsp;所以把&nbsp;<BR>
paging&nbsp;table&nbsp;initialize完整是件好事.exec时,&nbsp;也把新的paging&nbsp;<BR>
table&nbsp;initialize好,省得一执行又产生page&nbsp;fault.&nbsp;<BR>
exec也会检查新执行的程式是否有text&nbsp;page在主记忆体里,&nbsp;<BR>
有的话就顺便include进来.&nbsp;<BR>
&nbsp;<BR>
最後一个改进则是改进copy-on-write.&nbsp;在fork後,&nbsp;kernel检查parent在&nbsp;<BR>
主记忆体内的anonymous&nbsp;page,&nbsp;把他们都先拷贝起来.&nbsp;前面提到,&nbsp;<BR>
会变成anonymous&nbsp;page的资料,都是有被修改过的,&nbsp;而此page会在&nbsp;<BR>
主记忆体里,没有被swap&nbsp;out,表示最近曾被修改过.事先将这些&nbsp;<BR>
page复制的理由就是基於最近被修改的资料,&nbsp;可能child也会修改之.&nbsp;<BR>
这种情况在shell下面最常发生.&nbsp;shell常常自己fork很多次.&nbsp;<BR>
而每次fork後都会以相同的pattern来修改变数.&nbsp;<BR>
&nbsp;<BR>
最後本章提了一个测量结果,&nbsp;page&nbsp;fault次数有了明显的改进,&nbsp;已经改善到&nbsp;<BR>
比SVR3时好了.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;15&nbsp;More&nbsp;Memory&nbsp;Management&nbsp;Topics&nbsp;<BR>
&nbsp;<BR>
本章提了Mach的virtual&nbsp;memory管理.&nbsp;虽然是不同的设计,&nbsp;术语也不同,&nbsp;<BR>
但是和SVR4的VM架构有许多地方都是相同的.&nbsp;Mach的设计比较清楚易懂,&nbsp;<BR>
如果Chapter&nbsp;14看不懂,可以先看本章.&nbsp;4.4BSD&nbsp;VM架构就是基於Mach的.&nbsp;<BR>
不过4.4BSD的系统管理比较向SVR4.&nbsp;<BR>
&nbsp;<BR>
本章另一个重点是TLB一致性的处理.&nbsp;这是在多处理器下发生的问题.&nbsp;<BR>
如果kernel改了某个page的资料,&nbsp;他怎麽让其他的处理器知道并且更正&nbsp;<BR>
TLB的内容.&nbsp;&nbsp;基本上这是一件很麻烦的问题,&nbsp;尤其是CPU没什麽支援的状况下.&nbsp;<BR>
Mach的方法最简单,也最通用(不需要cpu支援,只要有个inter-processor&nbsp;lock),&nbsp;<BR>
但是浪费许多时间在synchronize上,&nbsp;没什麽效率.&nbsp;处理TLB应该算是&nbsp;<BR>
multiprocessor&nbsp;support内最麻烦的问题了,&nbsp;处理不好,一堆processor&nbsp;<BR>
都会浪费时间在synchronize上.&nbsp;<BR>
&nbsp;<BR>
盲目的synchronize造成不少的浪费,&nbsp;比较聪明的作法是分析什麽时候会修改TLB.&nbsp;<BR>
如果是发生在kernel的定址空间,&nbsp;那麽kernel可以透过谨慎的设计来避开TLB的修改,&nbsp;<BR>
那麽需要修改TLB的时机就只剩kernel所无法掌握的user&nbsp;processes了.&nbsp;而剩下的&nbsp;<BR>
这些状况也不是每种都要马上更改其他processor的tlb不可.&nbsp;因此可以省下了许多&nbsp;<BR>
不必要的麻烦.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;16&nbsp;Device&nbsp;Drivers&nbsp;and&nbsp;I/O&nbsp;<BR>
&nbsp;<BR>
介绍与device&nbsp;driver,&nbsp;io&nbsp;相关的课题.&nbsp;以及device&nbsp;driver&nbsp;与file&nbsp;system&nbsp;<BR>
间的互相配合,&nbsp;dynamic&nbsp;loading&nbsp;unloading等等.&nbsp;基本上就是device&nbsp;driver&nbsp;<BR>
必须提供哪些介面给kernel,&nbsp;可以使用kernel的哪些function&nbsp;call,和变数.&nbsp;<BR>
随Unix版本而异...&nbsp;<BR>
&nbsp;<BR>
Chapter&nbsp;17&nbsp;STREAMS&nbsp;<BR>
&nbsp;<BR>
STREAMS架构本来是为了解决character&nbsp;devices重复发展太多程式码和&nbsp;<BR>
buffering的问题,&nbsp;不过STREAMS设计得太强悍了,&nbsp;使得terminal&nbsp;driver,&nbsp;<BR>
pipe和网路driver都利用他来完成.&nbsp;STREAMS已被大多数的UNIX厂商所支持,&nbsp;&nbsp;<BR>
成为广为接受的标准,&nbsp;也是用来写网路driver较受欢迎的架构.&nbsp;<BR>
&nbsp;<BR>
STREAMS使用模组化的方式,&nbsp;让使用者可以依堆叠的方式循序推入处理模组,&nbsp;<BR>
而资料流则是通过一层层的模组达到驱动程式.&nbsp;反之亦然.&nbsp;terminal&nbsp;driver&nbsp;<BR>
就可以专心的处理与terminal沟通的细节,&nbsp;而与Unix系统其他的部份,以及使&nbsp;<BR>
用者介面,可以丢给上层的模组处理就好了.&nbsp;STREAMS架构详细的订定各模组间&nbsp;<BR>
要如何沟通和应有的&quot;举止&quot;.&nbsp;<BR>
&nbsp;<BR>
System&nbsp;V也定义了一个Transport&nbsp;Provider&nbsp;Interface及Transport&nbsp;Layer&nbsp;<BR>
Interface(TPI/TLI),&nbsp;功用类似BSD的socket介面,用来提供高阶程式设计&nbsp;<BR>
的标准介面.&nbsp;<BR>
&nbsp;<BR>
虽然STREAMS/TLI在本书写作之时好像颇具潜力,但是socket介面实在太强势了,&nbsp;<BR>
又有winsock助长声势,&nbsp;显然STREAMS在网路上没成气候,&nbsp;但是在其他方面&nbsp;<BR>
则发展得十分良好.&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
後记&nbsp;<BR>
&nbsp;<BR>
就这样把这本书有趣的内容整理完了.&nbsp;希望我的取材可以让那些略懂&nbsp;<BR>
Unix的人有更深入的空间,提高层次.&nbsp;其中我省略了许多Unix&nbsp;Kernel基&nbsp;<BR>
础的概念,希望不会让人不知所云才好.&nbsp;反倒是对Unix的简介好像写的&nbsp;<BR>
太详细了,&nbsp;这是因为我发现有很多中文书在这方面写错了....&nbsp;<BR>
&nbsp;<BR>
前言提到的那几本书(含本书)都很值得想了解Unix者阅读.&nbsp;有许多的细&nbsp;<BR>
节都是要仔细的整篇阅读才会了解的,&nbsp;像这样的摘要并不能完整的表达.&nbsp;<BR>
&nbsp;<BR>
书中对4.4BSD,&nbsp;Mach,&nbsp;SVR4/Solaris的描述,&nbsp;我都尽量提及了.&nbsp;希望对&nbsp;<BR>
Linux/FreeBSD/Solaris以及未来的GNU&nbsp;Hurd&nbsp;以及苹果的狂想曲的了解&nbsp;<BR>
有所帮助.&nbsp;另外你是否也跟我一样发现Sun真的不是一盏省油的灯,&nbsp;确&nbsp;<BR>
实有两三把刷子呢?&nbsp;<BR>
&nbsp;<BR>
本书有个缺点就是校正不太完整.&nbsp;内文reference到Section&nbsp;0好几次,&nbsp;但是&nbsp;<BR>
并没有Section&nbsp;0.&nbsp;应该是美中不足的地方吧!&nbsp;<BR>
&nbsp;<BR>
本书没有提到tcp/ip网路的部份,&nbsp;应参考Stevens,&nbsp;TCP/IP&nbsp;Illustrated&nbsp;<BR>
Volumne&nbsp;1,2,3.&nbsp;<BR>
&nbsp;<BR>
本书对shared&nbsp;library以及执行档的结构没有作深入的讨论,&nbsp;也是一个&nbsp;<BR>
遗憾...&nbsp;<BR>
&nbsp;<BR>


<CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>



</BODY>

</HTML>