招标网站开发文档,上海网站建设公司站霸网络,网站开发服务公司,开通网站软件的会计科目怎么做目录
内核关于per memcg lru lock的重要提交#xff1a;
计算虚拟地址转换基本机制
问题背景
swap换入流程
时奎亮的per memcg lru lock分享视频 内核关于per memcg lru lock的重要提交#xff1a;
f9b1038ebccad354256cf84749cbc321b5347497
6168d0da2b479ce25a4647d…目录
内核关于per memcg lru lock的重要提交
计算虚拟地址转换基本机制
问题背景
swap换入流程
时奎亮的per memcg lru lock分享视频 内核关于per memcg lru lock的重要提交
f9b1038ebccad354256cf84749cbc321b5347497
6168d0da2b479ce25a4647de194045de1bdd1f1d
计算虚拟地址转换基本机制
为了处理多应用程序的地址冲突 linux 系统在应用中使用了虚拟地址得益于硬件的MMU的广泛使用虚拟地址到实际内存的物理地址转化变得快速很多。 当虚拟地址送到cpu中后 系统先前检查TLB表中是否有这个地址 如果有直接返回物理地址 如果没有就去检查PageTable 如果pagetable中也没有这个地址系统产生一个page fault来给这个地址实际分配物理内存。
每个应用的page table 保存了虚拟地址到物理地址一一对应表 示意图如下所示 Page fault 在linux中采用了称之为lazy fault的处理策略 就是申请内存时并不实际分配物理内存 直到实际使用这块内存时才实际分配内存。例如得益于linux共享内存的设计如果应用申请的share lib已经被其他程序实际分配到内存。 那么后来的应用只要在pagetable中填上对应的页表项就好。不需要发生实际的IO,这个过程叫做 minor fault. 第一个使用share lib的应用因为需要把share lib的内容读到内存 需要有IO 的参与 称之为Major fault.
问题背景
自电子计算机诞生以来内存性能一直是行业关心的重点。内存也随着摩尔定律在大小和速度上一直增长。现在的云服务器动辄单机接近 TB 的内存大小加上数以百记的 CPU 数量也着实考验操作系统的资源管理能力。
作为世间最流行的操作系统 Linux 内核使用 LRULast Recent Used链表来管理全部用户使用的内存用一组链表串联起一个个的内存页并且使用 lru lock 来保护链表的完整性。
所有应用程序常用操作都会涉及到 LRU 链表操作例如新分配一个页需要挂在 inactive lru 链上 2 次访问同一个文件地址 会导致这个页从 inactive 链表升级到 active 链表 如果内存紧张 页需要从 active 链表降级到inactive 链表 内存有压力时页被回收导致被从 inactive lru 链表移除。不单大量的用户内存使用创建回收关系到这个链表 内核在内存大页拆分页移动memcg 移动swapin/swapout, 都要把页移进移出 lru 链表。
可以简单计算一下 x86 服务器上的链表大小x86 最常用的是 4k 内存页 4GB 内存会分成 1M 个页, 如果按常用服务器 256GB 页来算 会有超过 6 千万个页挂在内核 lru 链表中。超大超长的内存链表和频繁的 lru 操作造成了 2 个著名的内核内存锁竞争 zone lock 和 lru lock。这 2 个问题也多次造成麻烦系统很忙但是业务应用并没得到多少 cpu 时间 大部分 cpu 都花在 sys 上了。一个简单 2 次读文件的 benchmark 可以显示这个问题 它可以造成 70% 的 cpu 时间花费在 LRU lock 上。https://git.kernel.org/pub/scm/Linux/kernel/git/wfg/vm-scalability.git/tree/case-lru-file-readtwice
作为一个知名内核性能瓶颈 社区也多次尝试以各种方法解决这个问题 例如使用更多的 LRU list 或者 LRU contention 探测https://lwn.net/Articles/753058/。
但是都因为各种原因被 Linux 内核拒绝。
swap换入流程 cpu接到访问一个虚拟地址的命令 cpu需要把这个虚拟地址转化成物理地址于是先去访问TLB如果命中TLB返回物理地址 如果没有继续访问页表如果命中页表 返回物理地址 如果没有命中 产生page fault 在page fault处理程序中发现虚拟地址对应的页表项虽然present bit 为零但是内容非空所以这个地址在一个被交换到swap设备的页中。继续检查这个页是否在swapcache中如果在返回这个页地址加虚拟地址地址在页中的偏移如果不在获得一个内存页 到swap设备上读取内容填到这个页此处产生IO 为Major page fault. 接下了就上把这个页加到swapcache加入 LRU, 加入page table, 关联到所属的memcg 并且添加反向映射然后用户就可以正常使用了。 最后在某些机器上在更新mmu cache.(spark/ppc)
linux kernel 使用LRU来管理内存页。 Last Recent Used. 内核页管理方式如下图所示 lru 由2个链表组成一个是inactive list, 另一个是active list page fault新产生的页加到inactive list的头上 二次访问到的页从inactive list上提升到active list上 如果内存有压力回收时active list的页降级的inactive list inactive list页从尾巴上回收掉。
lru 页管理涉及到的内核数据有3个per node 上的 Lru_lock, page.flags上的 PG_lru bit 和per node 5个链表。linux 把所有用户使用的内存页都放在5个链表上 inactive anon, active anon, inactivec file, active file and unevictable list.
Lru_lock保护的对象有6个 加锁保护的时机如下 在2008年以前 memcg加入内核之前 内核使用一个per node lru_lock保护per node的lru lists. 当memcg引入内核后 lru list改成了 per memcg的模式每个memcg都有一组lru lists. 当每个memcg的页共同还在同一个lru lock上竞争时 显然不如给每个memcg一个lru lock 这样lock contention就会大大减小。 使用per memcg 的 lru_lock 要先解决一个问题 内存页不会一直在一个memcg上固定不变 页也许会被移动到其他的memcg上 也许memcg会销毁。 所以使用per memcg lru lock的关键就是如何在在lru lock 锁定期间 保证memcg固定。 开始很直接想到的是relock方案 page在memcg之间移动要获得lru_lock, 所以lru_lock relock可以保护page在memcg之间的移动 但是回顾上面读取swap device的例子 我们会在关联memcg之前加入lru list, 这个导致页所属的memcg不稳定 因而会拿错Lru_Lock 。解决的根本是改变页加入lru list和memcg的次序如下所示先关联memcg 然后在加入lru list. 关键步骤更新后页管理中的锁的使用次序页可以改变了 relock方案是可以用了。 但是relock 增加了lock 排队的机会 会导致性能下降。
更好的办法是不用lru_lock 保护memcg change, 比如拿出PG_lru bit做互斥 原本的page isoaltion次序是 get_page get lru_lock clear page lru delete page from lru list. 新的方法是 get_page; TestClearPageLRU; get lru_lock; delete page from lru list. page isolation互斥从lru lock上移到PG_bit, 通过线性获得PG_lru bit来保证。lru lock只用来保证list的完整性。加上一些code clean up. 新的lru lock保护对象只保留了 lists. 另外lru_lock使用时机还是不变。
时奎亮的per memcg lru lock分享视频
Linux Kernel Page Management and Iru List Locking Optimization - OpenAnolis龙蜥操作系统开源社区
