松原做网站平台,常熟市做网站公司,嘉兴市建设官方网站,建站模板哪里好早就想搞一下内存问题了#xff01;这次正趁着搞bigmemory内核#xff0c;可以写一篇文章了。本文旨在记录#xff0c;不包含细节#xff0c;细节的话#xff0c;google#xff0c;百度均可#xff0c;很多人已经写了不少了。我只是按照自己的理解记录一下内存的点点滴滴…早就想搞一下内存问题了这次正趁着搞bigmemory内核可以写一篇文章了。本文旨在记录不包含细节细节的话google百度均可很多人已经写了不少了。我只是按照自己的理解记录一下内存的点点滴滴而已没有一家之言不讨论不较真。1.最简单的内存使用
最简单的模型是冯.诺依曼提出的原始模型简单的把数据和指令存放在内存中然后机器从内存中取出指令和数据进行计算如下图所示当时的机器是为了执行一个特定的任务但是这种存储执行模型作为的一个最简单的核心为后代的逐步复杂化奠定了基础。我的观点还是一个概念或者其它什么东西之所以复杂是因为它经得起复杂。罗马帝国始终脱离不了城邦格局它经不起复杂它崩溃了2.分时系统内存模型 2.1.计划
一台机器执行一个任务太浪费资源了略过中间的挣扎直接到了分时系统时代一台机器可以执行多个任务了如果切换机制足够好这些任务可以满足低延迟需求。冯诺依曼机器的核心是处理器和内存处理器沿时间轴推进内存则空间平面上展开分时系统在时间轴上分割了多个任务它需要在空间平面上同样分割多个任务于是内存变成了一种共享的资源如何在多个任务之间分配这个单一的共享的内存资源成了后来技术发展的重轴戏。2.2.段式内存模型
段式内存模型将一个程序划分为不同的段不同任务的不同段处在内存的不同段当中如下图所示但是这种模型有两个显而易见的缺点第一很难满足一个大内存需求的任务第二一分就是一个段段必须处在一个连续的空间。2.3.虚拟内存
一个任务所需要的内存大小以及位置不应该依赖其它任务的内存的大小和位置并且内存的位置也不应该是永久性的任务使用内存就应该和人们使用公共厕所一样。程序任务只管自己的计算逻辑用到内存的时候不必自己操心应该有一个服务机构为其现场分配内存分配多少算好呢答案就是就可能少按照基本单位分配也就是说只分配程序现在用的那个内存即便说马上就要用另一块内存那也要等到时候再说这样就做到了公平和高效既满足了尽可能多的程序的内存需求又不会浪费任何不会用到的内存。内存页面的概念被提出后页就成了分配内存的最小单位而MMU则成了为程序分配内存的服务管理机构有了这个新机构应用程序再也不用考虑物理内存的位置的大小以及偏移问题了。虚拟内存的提出是革命性的在以前程序不得不维护自己段寄存器以明确自己所需内存的位置只要是有一个地址就可以根据段寄存器知道它位于内存中的什么地方也就是说那个时候程序是直接使用物理内存的。虚拟内存出现后MMU接管了内存管理的一切应用程序不必关心内存的位置和大小了。如果是32位系统那么程序被承诺可以使用高达4G的内存如果是64位系统...至于自己使用的内存在什么位置则不必关心可用的4G内存只是许诺等到需要的时候MMU自然会给你如果没有空闲内存自然会给你个说法。MMU作为一个仲裁和管理机构前提是大家必须信任它如果说初期的直接独占使用物理内存是王政时代 段式管理是贵族寡头时代的话虚拟内存管理则真正到了民主时代各项机构有条不紊运行。2.4.页式内存模型
页式模型顾名思义就是以页面为基础进行内存管理注意最终的内存页面并不直接和程序打交道它通过MMU和程序打交道。由于有了MMU这个中间层它负责将一个程序的虚拟内存地址映射到实际的物理地址怎么做到的呢当然是通过一张表即页表来查询的。由于采用了MMU这个中间层物理内存不再和程序直接打交道则物理内存的形式就变得不再重要它可以是内存条也可以是磁盘甚至可以是设备只要MMU能给出合理的解释并且按照应用程序访问内存的规则来访问这些实体并能给出正确的结果即可。这就使得文件映射设备映射成了可能。如下图所示虽然说“从虚拟内存映射到物理内存通过查表可以实现”但是具体的查表过程却非常复杂并不是简单的一对一的映射这么实现的。实际的实现是通过一个多极页表的方式实现的。所谓的多级页表是将虚拟地址分为不同的部分每一部分代表不同的索引。这样就可以按照内存的范围进行区域划分更好的进行页表的管理。具体的方法和图示无须google百度即可附一些细节-为何采用多级页表
在实际的实现中为何要使用多级页表而不是单级页表呢这是从管理成本来考虑的。由于是一个表那么它便有连续内存存储的需求这样才好根据索引来快速定位。如果是单层页表那么即使一个页面被分配也需要建立整个页表32位的情况下以4K页面为例需要20位要寻址页面基地址20位的话单级页表需要一下子建立4M大小的页表。使用多级页表并不是为了减少内存使用说实话如果把所有的4G映射都建立页表项的话采用两极页表还会浪费页目录表占用的4K空间然而并不能如此考虑问题内存使用分布是不遵循幂率的因此你不必考虑黑天鹅事件。大部分情况下不会建立太多的页表即使建立1000个页表它也会多数承载于连续的页目录项中很多的页表是不需要分配内存的。主旨就是将管理结构分级往前推往前推往前推本文最后会给出一个程序让你眼见为实地明白页表到底占据多少空间以及内存的分布如何影响页表占据内存空间的大小。2.5.换入换出机制
有点懵了怎么现在才开始说换入换出是不是顺序弄乱了不是说很早的UNIX时代就有换入换出了么如今Linux还保留着swap进程(其实是内核线程因为总有人较真说什么内核线程不能叫做进程看书看多了)这个名称。非也不是弄错了而是我想基于交换机制来谈一下虚拟内存的意义并不是讲换入换出机制本身。2.5.1.整体换入换出
这是最实际不过的了分时系统将一个进程拉到前台来运行的时候将该进程的映像从磁盘换到内存同时将正在执行的进程换出到磁盘。虽然简单但是却没有后续的可扩展性。这其实是基于最初的内存模型修正的而丝毫没有用到虚拟内存的优势。虚拟内存不关心进程不关心内存页面的位置切断了物理内存和进程的关系只关注页面本身页面的内容可以来自计算来自文件来自设备...事实上整体的换入换出模型更加适合虚拟化所谓的虚拟化指的是全部的包括CPU在内的虚拟化。它不适合虚拟内存既然CPU都是分时处理不同进程的内存为何就不能分页面映射给不同的进程呢2.5.2.页面换入换出
由整体换入换出的弊端引起的直接结果就是页面的换入换出。一个页面就是一个页面它不和进程进行关联只和页表项进行关联这是虚拟内存管理高效性和公平性之根本。单独页面的管理以及基于页面的换入换出机制虚拟内存之根本3.物理内存的角色
在使用虚拟内存之后物理内存的角色已经不再像早期那样重要它退化成了一个资源的角色作为一种资源原则上它可以是无限大的而且越大越好但是受制于以下的因素a.管理成本
是资源就要有效管理而管理本身也是消耗资源的它在各个系统上都有一个上限。b.体系结构的兼容性考虑
如果说从一张白纸重新作画那再简单不过了然而现实并非如此总线宽度为了兼容性并不能随意扩展。c.实现成本
计算机上的任何概念都是一个有限集更加明确的原则就是它不要求100%的好而是要求90%可用即可。d.电梯效应
超高层的摩天大楼不可能建造并不是因为底层承载不了上层的持续压力而是如果建成了高层大厦建得越高电梯占据的空间就越大达到阀值后电梯的空间将超越使用空间。这是管理成本的另一层含义只是更加严重些即使不能使物理内存无限大也可以让它更大PAE就是这个想法的产物。4.映射到物理内存
物理内存并非一定要和虚拟内存的大小一致如果是这样的话虚拟内存的意义是不明显的。以32位系统为例N个进程均被许诺有4G内存然而它们共享4G物理内存谁也不能同时用尽所有内存然而如果真的有这样需求的进程怎么办那只能频繁的换入换出了虽然也是可以实现但是更好的做法就是安装N*4G的内存可是这样的话好像又退回到了段式管理只是内存的实际位置不再确定只是将基于段的管理改成了粒度更细的页式管理而已。由于N的不确定性以及内存使用的不确定性没有必要安装那么大的内存最终的方案就是安装稍微大一些的内存比如16G32G64G的内存机器就足以飞起来了到此为止可能你还是不明白32位的系统如何去识别4G以上的内存。注意MMU使用页表来定位页面的位置只要页表项能填入一个大于32位的数字就能寻址到4G以上的内存--因为32位可以寻址4G(why...)加上硬件地址总线宽度能超越32位那就能定位到大于4G的内存定位到这个页面后将其映射回32位的某个地址即可。如下图所示记住物理内存仅仅就是一个资源的角色在不考虑兼容性以及管理成本的情况下当然越大越好并非非要和虚拟地址空间一致。在32位系统中进程的虚拟地址空间永远都是32位也就是4G的但是这4G空间的地址却是可以映射到任意的物理地址空间一切尽在MMU说白了就是第一页表项的映射指示到了任意的物理页面第二就是地址总线的宽度允许寻址到那个位置(否则虽然从程序上讲不会出错但是在地址总线上发射地址的时候会发生回绕)。程序员可以照着书上的例子写出代码但是没有什么书教你在哪些机器上这些代码可以得到你预期的结果5.Linux上的实现与PAE/PSE相关
上面说的加大物理内存供应的说法其实有一种实现那就是PAE。PAE是什么google吧如果怕google动不动就RESET那么百度也能得到结果PAE允许你寻址36位的物理地址空间也就是说允许你安装64G的内存。按照物理内存只是资源池的概念所有的32位进程共享所有安装的物理内存每一个进程寻址32位虚拟地址通过MMU实际可以访问36位的物理地址。是时候说一下Linux了对于实践者和怀疑论者以及书生乃至抑郁症患者抑或精神病而言没有任何高谈阔论可以比得上一个实际的例子了。5.1.Linux的地址映射方式
Linux采用了一种极其简单的地址映射方式那就是将内核空间的代码以及数据和实际的用户进程隔离开来怎么个简单法呢很简单那就是将进程的地址空间划分为用户态的3G和内核态的1G所谓的用户态就是非特权态对于那些爱看书的优秀学生而言他们熟悉的语言是第3特权护环不管怎么说反正就是进程可见的数据和代码的地址空间用户态的地址空间映射内核不过问而内核态的映射所有的用户态共享作为一个管理机构它是唯一的如下图所示用户态可以有自己的映射内核态的映射全部交给了内核本身内核简化了它可以用一种更加简单且高效的方式实现管理那就是一一线性映射也就是将一个连续的内核地址空间映射到一块连续的物理地址空间虽然最终的访存还是需要MMU但是起码不需要做复杂的管理工作了。映射到哪块连续的物理地址空间好呢当然是最初的空间好因为内核的映射位置不能依赖物理地址空间的大小。以上就是一一线性映射的由来但是为了满足动态的内核态服务的内存需求比如动态插拔的内核模块比如用户系统调用的临时需求内核的虚拟地址空间还要留下一部分用来映射这些动态的数据。最终内核态的虚拟地址空间的布局成了如下布局这样的布局本身没有什么问题特别是如果你理解Windows的自映射以及内核分页机制之后你就会发现Linux的方式是多么的原生态多么的环保。然而这种方式有一个疑问-现如今还不能成为问题为了保持一一映射的关系所有的一一映射的内存必须独占且常驻内存和最原始的冯诺依曼机器实现那种方式一样因此Linux的一一映射方式真正回归了原生态只是中间有一个MMU例行公事而已现在考虑PAE的模式我讨厌《尼罗河上的惨案》中那个穿西服的家伙那种方式如果启动了PAE意味着系统中存在大量的内存页面为了管理这些页面Linux内核必须为这些页面建立结构体即struct page。Linux系统是按照伙伴系统分配page的伙伴系统要求事先必须存在page的索引因此必须要考虑page结构体们占据的内存空间。作为基础管理数据结构这些page结构都处在内核的一一映射地址空间然而一一映射的地址空间大小是有限制的即896M按照一个page结构体32字节大小来计算的话你算一下能允许多少page被索引记住896M不能全都用于page结构内存管理只是Linux内核的一部分而已另外还有大头戏进程管理结果就是在现行的Linux内存管理模式下只能管理有限的page因此你并不能安装64G的内存在Linux系统上。但是作为一个通用且前卫的系统关键是Linus动不动就动粗口的情形下Linux有自己的解决方案其中不外乎以下两点a.使用大页面
一般而言一个页面4K这样为了索引大内存就需要大量的页面但是如果一个页面4M或者2M的话索引大量内存就不需要大量的页面了页面数量减少了页面管理结构所占据的内存空间也就减少了b.使用独立的4G/4G模式
虽然大页面可以缓解管理结构占据内存太大的问题但是并不能解决Linux支持一种4G/4G模式即不再将所有进程的最上面1G的内核空间共享而是每个进程的用户态独占4G虚拟地址空间切换到内核态时同时切换到另一个4G地址空间即独立的4G的内核地址空间内核态不再借用用户进程地址空间而是独立出来一个4G空间来寻址在X86上意味着不管是系统调用不管是中断还是异常陷入内核时都要切换CR3寄存器这意味着你要付出一些代价切换CR3的代价是昂贵的它不光是save/restore的代价更是取消了cache加速的代价5.2.Linux内核的管理成本
说白了Linux内核的管理成本太昂贵很多的管理数据结构都要占据内核的一一线性映射的896M的空间虽然进程结构task_struct结构体不大但是896M除以sizeof(struct task_struct)的话也不是一个很大的数再加上CR3指向的页目录页表等896M真的容不下什么太多的内容最根本的限制那就是这种机制限制了系统同时运行进程的数量但是Linux内核的这种原始内存映射的优点也显而易见那就是社区大牛们总是可以设计出一些精巧的数据结构往往在恶劣环境下写出的代码一定是高效的代码这同时也是微软的信条5.3.看一段代码展示管理成本
是时候展示一个简单的代码了。该代码让你看一下管理成本虽然很简单但是可以让你看到一个进程本身虽然不占据什么内存空间但是光其页表就占据大量的内存。在展示代码之前先看一个Linux内核的编译宏HIGHPTE该宏决定你能不能将页表这种吃内存的管理结构分配在高端内存即大于896M的物理内存也就是说如果你启用了该宏就不必在一一线性映射区域分配页表我的系统启用了该宏意味着页表都尽量分配在高端内存。以下是代码[plain] view plaincopy #include stdio.h #include stdlib.h #include sys/mman.h int main(int argc, char **argv) { int i 0, total 0; for (i 0; i 1024; i ) { int j 0; for (j 0; j 1024; j) { //保证每一个页表起码有一个页面被分配这样是为了填充满整个页目录 //所以要用FIX参数使用LOCK参数目的在于使其页表项中有内容否则就是缺页中断按需分配了 char *p (char *)mmap(i*1024*4096j*4096, 16, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|MAP_FIXED|MAP_LOCKED, -1, 0); //注释掉的是随机分配页面不必填充每一个页目录项 //char *p (char *)mmap(NULL, 16, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|MAP_LOCKED, -1, 0); if((int)p ! -1) { total ; *p 13; printf(addr:%p %d %d\n, p, i, j); break; } } } printf(total:%d\n, total); sleep(10000); } 执行前查看
/proc/meminfo
后由于页表分配在高端内存即896上的内存(我的系统2000M内存)其内容为HighTotal: 1628104 kB HighFree: 1261560 kB执行后total数目为768符合预期因为上1G的内存属于内核空间不能mmap。查看/proc/meminfo后HIGH内存减小减小多少自己算HighTotal: 1628104 kB HighFree: 1255360 kB如果不用FIX参数那么页表项同样也是建立那么多在我测试下来还多了很多1024个页表项全部建立成功但是HIGH内存占据反而减少了HighTotal: 1628104 kB HighFree: 1257344 kB这说明内存分配的布局也就是页表有与否会影响管理成本什么是High内存是大于896M的所有物理内存可用通过/proc/meminfo看出来6.IT技术并不绝对
到底安装多少物理内存算多可以算出来吗IT技术算精确技术吗我不觉得喜欢较真的人能彻底理解TCP。卫星技术要比IT技术高深TMD的多了怎么没有人能预测出欧洲卫星残骸坠落地球的具体地点追究TCP重传具体时间具体算法的人可能要彻夜计算卫星残骸坠落地点了由于精神高度紧张猝死的可能性比猜中50%的可能性更高实际上很多技术都是基于概率的都是追求90%的可用而不是100%的完美为何大家不必为卫星残骸坠落地球而担心因为地球上70%都是海洋陆地上人类聚集的地点不足1%所以砸中人的概率字计算吧。如果我被砸中了算是我对较真的神诅咒的一种报应吧但是并不绝对7.64位TMD64位
曾经大家不约而同地使用64位系统实际上没有谁的系统可以用到大内存就算吃内存的游戏32位也已经足够关键的是能申请到物理内存。只要物理内存大即可虚拟内存有谁会用到那么大呢你更多的受益于多核而不是64位。我们对时间的感觉要比对空间的感觉敏感得多。按照局部性原理一个CPU在同一时刻只能处理有限区域的内存数据时间比空间更重要强劲的CPU要比64位的虚拟地址空间更加有用虚拟地址空间并不是实际落实的物理地内存空间效率和速度体现在落实的物理内存上即使是物理内存的因素安装比较大的物理内存更多的是在于减少换入换出开销而不是为了满足同时访问大量内存的需求。即使有同时需要大量内存的程序也可以通过并发处理通过多核来将其平坦化我并不诋毁64位只是觉得按照资源池的概念你只需要在乎物理内存而无需在乎虚拟内存别提数据库我讨厌数据库因为它总是为自己占据大量磁盘需要很高的CPU处理能力而狂呼资源不够但是实际上早期的ER模型并不适合现在的大数据处理是数据库本身的问题而不是处理资源不够与其64位不如来个8核已经有了8核32位够了
