Chinaunix首页 | 论坛 | 博客
  • 博客访问: 165424
  • 博文数量: 22
  • 博客积分: 126
  • 博客等级: 入伍新兵
  • 技术积分: 459
  • 用 户 组: 普通用户
  • 注册时间: 2010-10-26 21:14
文章分类
文章存档

2013年(22)

我的朋友

分类: LINUX

2013-08-04 18:51:32

在执行伙伴系统算法分配页框以前,需要调用zone_watermark_ok()判断当前内存区中的页框数目是否在水位线以上,其实主要有两点要求:
1.是否满足预留的要求
内存区中的预留页框数目又有两方面的要求:
a.为紧急分配做的预留是否足够.zone->pages_min为内存区预留页框数目,常规分配时,内存区中的空闲页框数减去需要分配的数目后,应不少于zone->pages_min,将带GFP_ATOMIC,!__GFP_WAIT标志和实时进程是比较紧急的分配,可以使用部分预留的页框,带PF_MEMALLOC标志的是最紧急的分配,可以使用全部预留的页框.
b.为目标区在非本区的请求做的预留是否足够.请求页框时,必须指定请求的目标区,当请求的页框在高区(非高端内存),但是如果高区当前没有足够的页框,那么请求会顺次落到低区(HighMem->Normal->DMA),低区需要额外预留一部分页框,以应付某些子系统必须分配此区页框的情况.内核在实现这个需求是在每个区都设置了一个预留数组lowmem_reserve[MAX_NR_ZONES],zones[DMA]->lowmem_reserve[HIGHMEM]的意思就表示:如果请求的目标区在HIGHMEM,但是由于HIGHMEM和NORML区都没有足够的页框,请求落在DMA区后,在DMA区分配内存时,需要额外预留zones[DMA]->lowmem_reserve[HIGHMEM]个页框.对于zones[i]->lowmem_reserve[j],如果i==j,预留页框数目总是0,因为在目标区中分配页框时无需考虑额外预留,i>j的情况不存在,因为如果目标在低区的请求不会落到高区.
2.如果满足预留要求,各级order块的数目是否满足要求
伙伴系统算法的基本要求是要解决碎片问题,空闲页框不至于碎片化的前提是页框尽量合并成大块的方式存在,即页框的组织结构应该是一个11层的倒金字塔.分配页框时,需要严格限定预留页框在各级中的个数,如果分配页框后仍剩余free_pages个页框,那么需要满足限制条件:order=0页框的总数目不多于free_pages-min*1/2(min是需要预留的页框数目),order=1页框的总数目不多于free_pages-min*3/4,order=2页框的总数目不多于free_pages-min*7/8依次类推,如果小于order的各级都满足要求,则order级的页框数目至少为min/2^order个,按照这个限制条件可以根据2^(2*order)=min计算出order的最大值,即,如果min=1024,那么order的最大值为5.
阅读(5238) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~