0x15 虚拟内存(下)

本文深入探讨了虚拟内存管理中的页框分配策略,包括固定分配和优先级分配,以及全局置换和局部置换对性能的影响。文章详细解释了颠簸现象,介绍了工作集模型和缺页率(PFF)策略防止颠簸的方法。此外,还讨论了内核内存分配,如伙伴系统和slab分配,以及虚拟内存的其他考虑,如预先调页、页面尺寸选择和TLB范围等。

四、页框分配和颠簸

页框分配

也称帧分配,就是研究如何为各个进程分配一定的空闲内存。
如:现有93个空闲页框和2个进程,那么每个进程各得到多少页框?

页框分配会受到多方面的限制,例如,所分配的页框不能超过可用页框的数量,也必须分配至少最少的页框数,即每个进程所需要的最少的页框数。

分配至少最少的页框数的原因之一是性能。当指令完成之前出现缺页中断时,该指令必须重新执行,因此,必须有足够的页框来容纳所有单个指令所引用的页。

必须满足:每个进程所需要最少的页数
例子:IBM370-6处理SS MOVE指令:

  • 指令是6个字节,可能跨越2页
  • 2页处理from
  • 2页处理to

两个主要的分配策略:

  • 固定分配
  • 优先级分配

固定分配

为每个进程分配固定数量的页框数,有两种分配方式:平均分配和按比率分配。

平均分配——均分法
例:如果有100个页框,和5个进程,则每个进程分给20个页
按比率分配——根据每个进程的大小来分配
在这里插入图片描述

优先级分配

根据优先级而不是进程大小来使用比率分配策略。

如果进程Pi产生一个缺页

  • 选择替换其中的一个页框
  • 从一个较低优先级的进程中选择一个页面来替换

全局置换和局部置换

影响页框分配的另一个因素是页框置换。当有多个进程竞争页框时,页面置换算法可分为两大类:全局置换和局部置换。

  • 全局置换——进程在所有的页框中选择一个替换页面;一个进程可以从另一个进程中获得页框。一个问题是进程不能控制缺页率。
  • 局部置换——每个进程只从属于它自己的页框中选择。不能使用其他进程的不常用内存,所以会阻碍一个进程。

全局置换通常有更好的系统吞吐量且更为常用。

颠簸

当一个进程没有足够的页框,那么它很快产生缺页。然而,其所有页都在使用,它置换了一个页,但又立刻再次需要这个页。因此,会一而再地产生缺页中断,换出一个页,该页又立即需要换入。这种情况称为颠簸。

如果一个进程没有足够的页,那么缺页率将很高,这将导致:

  • CPU利用率低下.
  • 操作系统认为需要增加多道程序的道数
  • 系统中将加入一个新的进程

颠簸(抖动)=一个进程的页面经常换入换出
在这里插入图片描述
该图显示了CPU利用率与多道程序设计的道数之间的关系。初始时,道数增加,CPU利用率增加,直到达到最大值,如果此时道数还要继续增加,则开始系统颠簸,CPU利用率急剧下降,此时,为了增加CPU利用率和降低系统颠簸,必须降低多道程序的道数。

### 关于指令 0x73e15dfa 导致内存无法写入的原因分析 #### 错误原因 当遇到指令 `0x73e15dfa` 执行时发生内存地址 `0x00000001` 无法写入的情况,可能涉及以下几个方面: 1. **权限不足** 如果目标内存地址于只读区域或者未分配给当前进程的虚拟地址空间,则会触发访问异常。ARM64 架构下,寄存器状态显示栈帧中某些寄存器指向非法或受限内存区域[^1]。 2. **堆栈溢出** 当程序尝试向低地址(如接近零地址的置)写入数据时,可能是由于堆栈指针配置错误引起的。例如,在 ARM64 中,`sp` 或者其他基址寄存器被意外修改到无效范围[^1]。 3. **缓存一致性问题** 对特定硬件平台而言,CPU 缓存可能导致实际物理内存更新滞后。如果软件逻辑依赖即时可见性但未能正确同步,则可能出现看似不可写的状况[^2]。 4. **优化引发的问题** 高度优化后的代码可能会改变原始算法的行为模式,比如通过减少中间变量来节省资源的同时也增加了复杂性和潜在风险。这里提到从 O0 至 O1 的转变减少了不必要的内存交互却也可能引入新的隐患[^2]。 5. **外部因素干扰** 包括但不限于操作系统层面的安全机制限制、驱动程序冲突以及恶意攻击等都可能导致此类现象的发生[^4]。 #### 解决方案建议 针对以上各种可能性可以采取相应措施加以应对: - **验证并调整权限设置** - 确认应用程序是否有足够的权利去操作指定段落内的所有字节单元。 - **审查源码结构设计合理性** - 特别关注那些经过高度压缩精炼之后的部分,确保它们仍然保持清晰易懂且功能准确无误。 - **实施更严格的初始化流程** - 在任何试图操纵之前先进行全面细致地预处理工作,包括但不限于清空缓冲区内容、重置计数器初始值等等动作。 - **加强调试工具运用频率** - 借助现代IDE内置的强大特性快速定具体哪一步骤出了差错;同时也可以考虑引入专门用于检测这类特殊场景下的插件扩展包辅助排查过程。 以下是基于 Python 实现的一个简单示例脚本用来演示如何安全有效地去除 PKCS#7 类型填充材料从而避免因不当处理引起类似的崩溃情况再次重现: ```python import sys def pkcs7_unpadding(data): """Remove the PKCS#7 padding from a given byte string.""" pad_val = int.from_bytes([data[-1]],'big') return data[:len(data)-pad_val] if __name__ == '__main__': if len(sys.argv)!=3 : print('Usage: python unpad.py <input file> <output file>') exit(-1) infilename,outfilename=sys.argv[1],sys.argv[2] try: with open(infilename,'rb')as fin: raw=fin.read() clean=pkcs7_unpadding(raw) with open(outfilename,'wb')as fout: fout.write(clean) except Exception as errormsg: print(errormsg) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值