背景

• read the fucking source code! --by 鲁迅
• a picture is worth a thousand words. --by 高尔基

说明：

1. kernel版本：4.14
2. arm64处理器，contex-a53，双核
3. 使用工具：source insight 3.5， visio

1. 介绍

之前的系列内存管理文章基本上描述的是物理页面的初始化过程，以及虚拟页面到物理页面的映射建立过程，从这篇文章开始，真正要涉及到页面的分配了。接下来的文章会围绕着分区页框分配器(zoned page frame allocator)来展开，其中会包含大家熟知的buddy system分析。

本文会先围绕着涉及到的数据结构，以及大体的流程做一个整体的分析，后续会针对这个流程中的细节进行更详细的拆解，我已经迫不及待了。

2. 数据结构

2.1 概述

先回顾一下（五）linux内存管理zone_sizes_init的数据结构图：

上述的结构体，描述的是下面这张图：

node ---> zone ---> page的组织关系，其中buddy system中，页面都是以2的次幂来组织成链表，比如free_area[0]，对应的是1个page链表，其中又根据不同的migrate_xxxx类型来组织，如下图：

arm64中max_order默认值为11，page_size=4k，因此总共有0 ~ 1011个链表数组，链表中的连续的页面为2^0 ~ 2^10，对应大小为4k ~ 4m。

可以通过cat /proc/pagetypeinfo来查看下系统的页面信息，如下图：

可以通过cat /proc/zoneinfo来查看node的zone计数信息：

2.2 migrate类型

从上边的图中可以看到migrate_xxx不同的迁移类型，表明页面的移动属性，并在可能的情况下通过将相同属性的页面分组在一起来抑制内存的连续碎片。

enum migratetype {
    migrate_unmovable,
    migrate_movable,
    migrate_reclaimable,
    migrate_pcptypes,   /* the number of types on the pcp lists */
    migrate_highatomic = migrate_pcptypes,
#ifdef config_cma
    /*
     * migrate_cma migration type is designed to mimic the way
     * zone_movable works.  only movable pages can be allocated
     * from migrate_cma pageblocks and page allocator never
     * implicitly change migration type of migrate_cma pageblock.
     *
     * the way to use it is to change migratetype of a range of
     * pageblocks to migrate_cma which can be done by
     * __free_pageblock_cma() function.  what is important though
     * is that a range of pageblocks must be aligned to
     * max_order_nr_pages should biggest page be bigger then
     * a single pageblock.
     */
    migrate_cma,
#endif
#ifdef config_memory_isolation
    migrate_isolate,    /* can't allocate from here */
#endif
    migrate_types
};

• migrate_unmovable：无法移动和检索的类型，用于内核分配的页面，i/o缓冲区，内核堆栈等；
• migrate_movable：当需要大的连续内存时，通过移动当前使用的页面来尽可能防止碎片，用于分配用户内存；
• migrate_reclaimable：当没有可用内存时使用此类型；
• migrate_highatomic：减少原子分配请求无法进行高阶页面分配的可能，内核会提前准备一个页面块；
• migrate_cma：页面类型由cma内存分配器单独管理；
• migrate_isolate：内核会暂时更改为这种类型，以迁移使用中的系列活动页面；

2.3 __gfp_xxx请求标志（gfp_mask）

__gfp_xxx为内部使用的标志，在include/linux/gfp.h文件中，外部不应该使用这些flag，这些标志在页面申请的时候使用，其中gfp表示get free page。

罗列部分如下：

• __gfp_dma：请求在zone_dma区域中分配页面；
• __gfp_highmem：请求在zone_highmem区域中分配页面；
• __gfp_movable：zone_movalbe可用时在该区域分配页面，同时表示页面分配后可以在内存压缩时进行迁移，也能进行回收；
• __gfp_reclaimable：请求分配到可恢复页面；
• __gfp_high：高优先级处理请求；
• __gfp_io：请求在分配期间进行i/o操作；
• __gfp_fs：请求在分配期间进行文件系统调用；
• __gfp_zero：请求将分配的区域初始化为0；
• __gfp_nofail：不允许请求失败，会无限重试；
• __gfp_noretry：请求不重试内存分配请求；

2.4 alloc_xxxx分配标志（alloc_flags）

分配标志定义在mm/internal.h文件中，在页面的分配函数中与gfp_mask分开使用，这些标志时用于内部函数的分配。

• alloc_wmark_min：仅在最小水位water mark及以上限制页面分配；
• alloc_wmark_low：仅在低水位water mark及以上限制页面分配；
• alloc_wmark_high：仅在高水位water mark及以上限制页面分配；
• alloc_harder：努力分配，一般在gfp_mask设置了__gfp_atomic时会使用；
• alloc_high：高优先级分配，一般在gfp_mask设置了__gfp_high时使用；
• alloc_cpuset：检查是否为正确的cpuset；
• alloc_cma：允许从cma区域进行分配；

2.5 struct alloc_context

在页面分配的过程中，有一个结构叫struct alloc_context，这个结构用于存储各个函数之间传递的参数。这种思想在平时的coding中是可以去借鉴的，比如有些人写代码很喜欢用全局变量，改成这种context的形式，在各个函数之间传递显得更为优雅。直接看代码吧：

/*
 * structure for holding the mostly immutable allocation parameters passed
 * between functions involved in allocations, including the alloc_pages*
 * family of functions.
 *
 * nodemask, migratetype and high_zoneidx are initialized only once in
 * __alloc_pages_nodemask() and then never change.
 *
 * zonelist, preferred_zone and classzone_idx are set first in
 * __alloc_pages_nodemask() for the fast path, and might be later changed
 * in __alloc_pages_slowpath(). all other functions pass the whole strucure
 * by a const pointer.
 */
struct alloc_context {
    struct zonelist *zonelist;
    nodemask_t *nodemask;
    struct zoneref *preferred_zoneref;
    int migratetype;
    enum zone_type high_zoneidx;
    bool spread_dirty_pages;
};

• zonelist：用于分配页面的区域列表；
• nodemask：指定node，如果没有指定，则在所有节点中进行分配；
• preferred_zone：指定要在快速路径中首先分配的区域，在慢路径中指定了zonelist中的第一个可用区域；
• migratetype：要分配的迁移页面类型；
• high_zoneidx：将分配限制为小于区域列表中指定的高区域；
• spread_dirty_pages：脏区平衡相关；

3. build_all_zonelists

在上篇文章中描述到各个zone，实际上各个zone最终组织起来是在build_all_zonelists函数中实现的：

整体完成的工作也比较简单，将所有node中可用的zone全部添加到各个node中的zonelist中，也就是对应的struct pglist_data结构体中的struct zonelist node_zonelists字段。

这一步之后，准备工作基本就绪，进行页面申请的工作就可以开始了。

4. alloc_pages

下面的流程开始真正的页面申请了，在内部的实现中通过__alloc_pages来实现的：

在页面分配时，有两种路径可以选择，如果在快速路径中分配成功了，则直接返回分配的页面；快速路径分配失败则选择慢速路径来进行分配。

4.1 fast path

快速路径分配，是通过get_page_from_freelist来完成的，具体的流程及分析如下图所示：

4.2 slow path

慢速路径分配，最终也会调用get_page_from_freelist，流程分析如下：