度所写的后续页面以写到磁盘上。
可能存在一些应用程序执行大量的随机 I/O，即 I/O 模式不满足后写算法的要求，因而导致所有页面驻留在内存中，直到 syncd 守护程序运行为止。如果应用程序修改了内存中的很多页面，那么在 syncd 守护程序发出 sync() 调用时，这会使得向磁盘写入大量页。
将 ioo 命令与 JFS maxrandwrt 参数一起使用，可调整阈值。缺省值为 0，表示随机后写是禁用的。将该值增加到 128 表示一旦文件驻留于内存的页达到 128 页，随后的任何脏页都将被调度写入磁盘。而这些页将在调用 sync() 后刷新。
对于增强型 JFS，ioo 命令选项 j2_nRandomCluster（-z 标志）和 j2_maxRandomWrite（-J 标志）用于调整随机后写。两个选项缺省值都为 0。增强型 JFS 的 j2_maxRandomWrite 选项和 JFS 的 maxrandwrt 功能相同。即它限定了每个文件可以留在内存中的脏页数。j2_nRandomCluster 选项指定了可以被视为随机的两次连续写入之间的簇数。
也就是说：
一个规则先说，这是前提：当一个fs cache page必须被另外使用时，一定是minfree已经达到了，否则系统只用从free list中取未用页来用即可。 ●顺序后写造成的dirty page，当真正需要用到这些页时，minfree已经达到，而minfree达到时，一定会做先做commit dirty page的事情，所以不用占用paging space；
●缺省情况下，随机后写完全是关闭的，所以随机后写不会导致fs cache被使用，也就不可能产生dirty
●非缺省情况下，随机后写打开，那么情形同顺序后写。
所以您设想的dirty fs cache page需要换出到paging space的可能性并不存在。
[ 本帖最后由 larryh 于 2008-6-20 01:36 编辑 ]
原帖由 FromHell 于 2008-6-19 21:54 发表
对于AIX ....可执行程序文件的代码段 属于计算内存
虽然对于这些段来说(代码 段和初始数据段) 其实是有文件部分在磁盘上对应的...但是最
后还是会变成计算内存
这里有个转化的概念 OS 的Loader在装入可执行文件时...因为从disk 装入 ...这时所使
用的还是属于NonComp..
一旦发生指令预取的page fault....则NonComp会转为Comp
这一点，我倒没有看到有足够详细的官方资料来证明是或否
由此我引申想到两个有趣的问题：
1、某个页当前属于非计算内存还是计算内存，是否有专用的页标志来标明？我怀疑没有，因为IBM自己，都可能对内存页的那么多种用途到底算什么类型没有完全一致意见（除了典型的，占用量大的类型没有什么异议外）。比如nmon和topas显示的非计算内存和计算内存比例就不同。
2、这个更加有趣，而且有兴趣有精力的可以做做试验（需要POWER汇编的知识，至少可以查看特定代码的十六进制数据体现是什么，以在内存中定位出来，我没做）。有没有用户进程可访问的非计算内存？按照概念来说不应该有。那么如果用户进程去写非计算内存，应当会被操作系统发现越权访问不属于自己的内存，而把它干掉同时产生coredump。
如果您说的代码实际被引用到，会导致其转化为计算内存这一点，确实是AIX的标准行为，那么这个计算内存算不算这个进程自有？
这样会有这么几种情况：
●代码已经被执行过，所以它是计算内存： 如果它属于用户进程自有：自然这个进程可以修改已经被执行过的自身代码——可以设计一个试验来验证；
如果它不属于用户进程，则必然属于系统进程：这个进程修改已经被执行过的自身代码的尝试将导致coredump；
●代码尚未被执行过，所以它是非计算内存：
非计算内存不应该属于进程自有，所以试图修改它会造成coredump。
又要翻船
在infocenter找到明确说明：
Pages that are part of working segments are written to paging space; persistent segments are
written to disk.（不过没有写是paging space还是file，还有机会。。。）
中午吃多了。。。嗨，怎么没想起来lrud是罪魁祸首，它会根据page情况调用磁盘写，否则也不会猜想两个进程争相刷新磁盘。。。
原帖由 larryh 于 2008-6-20 02:40 发表
1、某个页当前属于非计算内存还是计算内存，是否有专用的页标志来标明？我怀疑没有，因为IBM自己，都可能对内存页的那么多种用途到底算什么类型没有完全一致意见（除了典型的，占用量大的类型没有什么异议外）。比如nmon和topas显示的非计算内存和计算内
存比例就不同。
2、这个更加有趣，而且有兴趣有精力的可以做做试验（需要POWER汇编的知识，至少可以查看特定代码的十六进制数据体现是什么，以在内存中定位出来，我没做）。有没有用户进程可访问的非计算内存？按照概念来说不应该有。那么如果用户进程去写非计算内存，应当
会被操作系统发现越权访问不属于自己的内存，而把它干掉同时产生coredump。
如果您说的代码实际被引用到，会导致其转化为计算内存这一点，确实是AIX的标准行为，
那么这个计算内存算不算这个进程自有？
这样会有这么几种情况：
●代码已经被执行过，所以它是计算内存：
如果它属于用户进程自有：自然这个进程可以修改已经被执行过的自身代码——可以设计一
个试验来验证；
如果它不属于用户进程，则必然属于系统进程：这个进程修改已经被执行过的自身代码的尝
试将导致coredump；
●代码尚未被执行过，所以它是非计算内存：
非计算内存不应该属于进程自有，所以试图修改它会造成coredump。
发扬一不怕死，二不怕水，死猪不怕开水烫的精神，继续水。偷偷跟您说一声，为了保证灌水质量，我连晚饭都没吃，只喝水！力争保持清醒！忽然想起来，刚说了一句，现在LU高手越来越多，保不准什么时候就被一刀毙命！乌鸦嘴啊！
以下来自infocenter和我自己的理解，请大家多多水场。http://publib.boulder.ibm.com/in ... _memory_mngment.htm
VMM管理将memory分成page，缺省page大小4KB，但aix操作系统支持更大的page，例如16M，但对于非4k的page，aix不能处理page in/out，只能将其pin在real memory中，aix中每256M的memory只能采用一种page size（aix支持混合使用），而且不需要重新启动，（需要预先将vmo参数large_page_heap_size=1以允许其它page），只需更改vmo
参数到需要的大小，。但注意，使用其他大小的 page，不能交换。 与vmm不同， real memory (RAM)只有4k page, vmm管理程序需要将其page与real memory的4k对应（或者与磁盘交换区对应，就是page out出去了）。
vmm使用一些算法来进行对应。
Virtual-memory segments分为persistent segments 或者 working segments. Virtual-memory segments同时还被分为computational or file memory
如果需要访问的Virtual-memory pages不在real memory，则引起page fault中断 Page faults又可能是new-page faults或者repage faults，最近一段时间（这个时间长短好像是lrud扫描完一遍内存pool的时间，有待确认。lrud不停地循环扫描内存pool，内存pool的大小根据机器拥有的物理内存多少和cpu数量有关，vmstat -v可以看到memory pool的数量，每个pool对应lrud的一个线程）第一次访问此页是new page fault，如果在这段时间第二次发生此page faults，则是repage faults。如果发生repage fault，系统会记录下来vmstat 1 的re一项既是。
Persistent和working segments
Persistent内存页如larry老大所说，就是在磁盘上有对应的，无论程序，数据文件还是cache（其实也是为数据文件准备的）， working segment是临时生成，例如malloc申请的。但由于单位是segment（256M），所以并不能按照4k断定那个是persistent，那个是working，而是vmm根据内存申请的特点来存放对应的page（我猜想，不确定，有待探讨）。也就是说，系统一定知道那些page是persistent，那些是working，因为这些page在初始化使用的时候，是在不同的段里面申请的！如果读写文件，vmm就在persistent segment分配page给请求者（打开文件通常由lvm内核操作，所以是系统调用），而程序通过malloc申请，即使保存的是文件的一部分（通过memcpy过来），但系统依然认为是working，在working段分配。
如果persistent里面的page被修改并且不能在real memory保存(什么情况下不能保存？待确定），则vmm将其写回到磁盘上对应的数据文件区。如果没被修改，则直接丢弃，不需要io，以后再有需求，重新读回来，因为磁盘上有对应文件（数据）。
c程序在执行的时候，操作系统vmm会自动分配stack/data段（working），heap段（working）, program text段（persistent）， shared lib段（persistent），每段256M，但只是一个虚拟空间，程序真正使用的时候，才会占据一个又一个4k，才会对应到real memory
Working segments是个临时区域，仅仅存活于程序执行期间，磁盘上也没有对应的数据文件。一点例外，系统内核的text和shared library本来应当保存在persistent段（因为内核也是程序，而程序的这些区域应当是persistent内存），但是他们也被算作working的，难道是防止系统运行过程中系统内核文件被误删除直接导致系统崩溃？而给大家留个缓冲时间，因为这些文件不会再从磁盘读入，只读一次，以后即使内存不够，也不会如同其他
程序文件直接丢弃，而是交换到paging space! 推论：如果误删除了系统内核文
件（限于执行文件和调用库，参数文件不算），千万别停机，系统还会正常工作！想办法还
能从内存中找回来。
Persistent-segment还有更多的类型。Client segments 是用于远程文件，例如nfs mount过来的，这些page如果需要交换出去，则写回原位置或者丢弃（如果没有修改），而不会交换到交换区（我印象中4.3.3似乎是写本地交换区，估计是现在认为网络足够快了）。Journaled和deferred segments是persistent segments，必须进行原子操作写（原子操作大家都知道，就是同时只允许一个线程进行写，别的必须等待，不能并行写） 如果 journaled或者deferred segment需要从real memory偷页 (paged out), it must be written to disk paging space unless it is in a state that allows it to be committed (written to its permanent file location).
这是真正的疑点所在，哪些数据属于Journaled和deferred？我猜想是jfs的inode之类的数据，deferred呢？不确定。先放到这，回去找aix kernal internal继续专研。
Computational和file memory
Computational memory也就是computational pages, 包含working-storage segments或者program text (executable files) segments. 也就是说计算内存包括working段或者程序代码。 又出现疑点，程序代码以往我是当成非计算内存的，难道又疏忽了。。。？
file memory是所有其他的内存页，交换到自己原有对应的文件，这没什么说的。
但愿是5.3与以往版本有出入，否则误人子弟，诲人不倦啊！专研几天先。
多谢Larry老大给我们指出了一条康庄大道，道上还堆砌了无数荆棘。。。
原帖由 larryh 于 2008-6-20 21:12 发表
jfs2用的是client段，这个和jfs不同，也就是说应当和NFS的处理方法完全一样了。至于fs cache在NFS和JFS之间表现有什么不同我还不清楚
黄老大能详细指点一下？ 永久存储
永久存储分页是一些包含永久数据（也就是说，重新启动后仍然存在的数据）的分页。这种永久数据就是文件数据。因此，永久存储分页就是缓存在内存中的部分文件。
当经过修改的永久存储分页需要换出（从内存移动到磁盘）的时候，会将它写入到文件系统中。如前所述，可以直接释放没有经过修改的永久存储分页，无需将其写入到文件系统中，