- 论坛徽章:
- 4
|
本帖最后由 塑料袋 于 2012-03-28 23:48 编辑
占位,计划谈page compaction及migration的提出目的,实现手段。
目的:
1) NUMA结构,进程迁移,则进程的内存页面若也迁移至目标CPU,则对这个进程来说,访存最快。
2) 内存热插拔
3) huge page
4) buddy造成的的内存碎片化:buddy有求必应,一律从满足要求大小的,最小的连续内存片段分配,但是无视分配的性质。考虑场景如下,1234共4个页:
a) slab临时性的分走[1],随时可能shrink cache收回,此时剩余[2],[34]
b) 某driver长期性的分走[2],这页不可能收回,此时剩余[34]
c) slab临时性的分走[3],随时可能shrink cache收回,此时剩余[4]
d) 某driver长期性的分走[4],这页不可能收回,此时无剩余
e) slab释放了[1],此时剩余[1]
f) slab释放了[3],此时剩余[1],[3]
由此导致碎片化。但若将内存按照分配的性质分类,[12]归于movable,临时性的分配从这里分;[34]归于unmovable,长期性占用从这里分,则不会产生这种情况。
将内存按照分配的性质来来划分成几部分,需要一个划分的依据。以前的版本中分了三部分:MOVABLE,RECLAIMABLE ,UNMOVABLE 。movable最可能被随时释放,unmovable最不可能被释放。buddy中的每个order,都被分成这3部分。
这三部分中,那一部分到底应涵盖多少内存,不应设置成死的,而应根据分配的情况来动态调整。即:
unmovable不够,则先自reclaimable借,后自movable借。
movable不够,则先自reclaimable借,后自unmovable借。
原则为尽量少改动内存的易释放性,从最接近自己的那类中来借。
当本order管理的内存中借也借不着时,那只好在斥逐于更高的order,整个拿来一块,将这一块分成小块,除了分配出去的那小块外,其他的尽量不更改易释放性。
MOVABLE中的内存是重头戏,除了只分配给那些临时性的请求外,对这些内存,还可以进行compaction及migration。
compaction发生于内存不足时,基本上是个和page reclaim并列的逻辑。自头至尾释放zone内的页,这些页都在lru中,且页与页之间可能有缝隙,即碎片化;自尾至头分配zone内的页,这些页都属于movable,且分配的原则为见缝插针,中间不产生缝隙。将被释放页的内容复制到新分配的页,同时依据被释放页的反向映射,修改所有引用被释放页的pte。
占位待续 |
评分
-
查看全部评分
|