物理内存申请过程分析

http://www.linuxidc.com/Linux/2012-09/70711p3.htm

memory_pressure 分配内存时候++,释放内存--

inactive_target

z->pages_min

 z->pages_low

 z->pages_high


栈变量

direct_reclaim : 是否能从inactive_clean中分配一个页面,成立条件:分配一个页面&&不是内存管理程序&&(gfp_mask & __GFP_WAIT)

1 首先尝试从zone的free_area中分配内存

for (;;) { zone_t *z = *(zone++);

if (!z) break; if (!z->size) BUG();

        if (z->free_pages >= z->pages_low) {

             page = rmqueue(z, order);    //尝试从free_area中分配

            if (page)       

               return page;

           } else if (z->free_pages < z->pages_min && waitqueue_active(&kreclaimd_wait)) {

                    wake_up_interruptible(&kreclaimd_wait);  //唤醒kreclaimd

           }

}

2 尝试使用高水位进行分配内存 page = __alloc_pages_limit(zonelist,order,PAGES_HIGH,direct_reclaim); 

该函数主要考虑从free + inactive_clean中分配,如果是分配一个页面,则可能从inactive_clean中分配,或者从free_area中分配

if (z->free_pages + z->inactive_clean_pages > water_mark) {

     struct page *page = NULL; /* If possible, reclaim a page directly. */

     if (direct_reclaim && z->free_pages < z->pages_min + 8)

                 page = reclaim_page(z);

               /* If that fails, fall back to rmqueue. */

              if (!page)

                  page = rmqueue(z, order);

              if (page)

                 return page;

}

3  尝试使用低水位进行分配内存 __alloc_pages_limit(zonelist,order,PAGES_LOW,direct_reclaim)

该函数主要考虑从free + inactive_clean中分配,如果是分配一个页面,则可能从inactive_clean中分配,或者从free_area中分配

4 如果还没有分配到页面则唤醒kswap交换内存,并执行调度(给kswap运行的机会),之后以最低水位执行page = __alloc_pages_limit(zonelist,order,PAGES_MIN,direct_reclaim);


5  如果还没有申请到内存 ,有可能有两个原因,执行不同策略

- 我们正在进行分配一个大的内存块(order比较大) - >将页面移动到空闲列表中,直到成功

- 我们在内存上真的很紧 - >等待kswapd等待队列,直到内存被释放

首先来看对与普通程序 非内存管理程序


物理内存申请过程分析_第1张图片
对于分配大块内存情况

对于分配大内存情况首先用page_launder清洗不活跃脏页面。然后尝试从不活跃脏页面释放页面,之后分配页面


物理内存申请过程分析_第2张图片
内存真的紧张

到了这里内存已经非常紧张,如果不允许分配失败,__GFP_IO(内存查找期间可以进行IO操作,只有这样才有必要进行交换释放页面,中断中不允许io操作,太慢)

首先同步唤醒kswapd进行清洗页面,如果申请一个页面返回最开始处进行分配

否则 如果不允许失败则释放page,order=下0则到try_again 处重新进行分配


6 最后实在分配出来则执行后面逻辑


物理内存申请过程分析_第3张图片
最终逻辑

首先如果是分配单个页面的普通程序肯定不会走到这里,如一种所说是当oomkiller杀进程的时候分配页面,另外一种就是管理程序或者普通程序

申请多个页面 


7 最总还没有分配到则

printk(KERN_ERR"__alloc_pages: %lu-order allocation failed.\n",order);

returnNULL; 

由此可见申请大的连续物理页面一定要小心,因为很容易申请失败。

你可能感兴趣的:(物理内存申请过程分析)