在软件设计时,我们一般要从需求中提取出抽象(类或者数据结构),然后围绕这些抽象设计相关的算法。内存管理自然也不能例外,这两节我们来看看为了管理为了物理内存以及整个虚存空间,linux提取哪些抽象,提取这些抽象背后的动机是什么?这些抽象之间的关联是什么?
注:本文展示的结构体定义来自2.6.24版本的内核。
1.最顶层——节点 Node
Node(内存节点)是因为NUMA的出现而产生的抽象。NUMA(Non Uniform Memory Access)即非一致性内存访问,主要出现在大型机上。参考下图,在这种系统中,每个CPU都有本地内存,但也可以通过总线访问其他CPU的本地内存;总线上还有一个公共的内存模块,各CPU都可以通过系统总线访问。显然,对某个具体的CPU来说,其访问本地内存的速度是最快的,而通过总线访问其他CPU本地内存的速度要慢,而且还可能面临着竞争。可见,在这样的系统中,虽然内存的地址是连续的,但“质地”却不均匀,因此我们需要将这些制定不均匀的内存分开管理,每一个内存模块称之为一个内存节点Node。
与NUMA相对的是UMA即一致性内存访问,在这种系统下,所有处理器对内存的访问具有相同的速度,有就是说整个内存质地是均匀的,因此只对应一个内存节点Node。传统的计算机中采用的就是UMA结构,本文主要分析UMA结构。
Node对应的数据结构为pglist_data,其定义如下(对定义进行了简化,去掉宏开关中的内容):
<include/linux/mmzone.h>
typedef struct pglist_data {
struct zonenode_zones[MAX_NR_ZONES];
structzonelist node_zonelists[MAX_ZONELISTS];
intnr_zones;
struct page*node_mem_map;
structbootmem_data *bdata; /*自举内存分配器*/
unsignedlong node_start_pfn; /*该节点的其实页帧逻辑编号,全局唯一*/
unsignedlong node_present_pages; /* total number of physical pages */
unsignedlong node_spanned_pages; /* total size of physical page
range, including holes */
intnode_id;
wait_queue_head_tkswapd_wait;
structtask_struct *kswapd;
intkswapd_max_order;
} pg_data_t;
给你一整块地,你该怎么打理?当然是将整块地划分成不同的区域,某个区域用来盖房子,某个区域用来种农作物,其他的区域用来种经济作物。这里也一样,内存节点将整个内存再细分为区域Zone,结构体成员node_zones就表示内存节点所划分的内存区域,而nr_zones指示所分区域的数量。一般分为三个区:ZONE_DMA、ZONE_NORMAL和ZONE_HIGHMEM,每个区域都有其特殊用途。ZONE_DMA在低端地址处,该区域主要是为ISA(Industry Standard Architecture)设备而设置;ZONE_NORMAL区域的物理内存通过某个固定的偏移映射到内核的虚拟地址空间;如果内存空间超过1G,则还会有ZONE_HIGHMEM,设置该区域的目的主要是为了使得内核可以访问1G以外的内存空间。在X86架构下,区域的划分一般如下:
ZONE_DMA First —— 16MiB ofmemory
ZONE_NORMAL —— 16MiB -896MiB
ZONE_HIGHMEM —— 896 MiB -End
当需要申请一个内存页Page时,alloc_page的调用者一般会指定从哪个区域分配,但如果该区域内存不够该怎办,这时就需要指定“备选”区域,可以有多个备选区,优先级从高到底排列,表示当指定区域的内存不足时,优先从第一个备选区分配,如果第一个备选区仍然内存不足,则尝试第二个备选区,依次类推,这就是所谓的分配策略。结构体成员node_zonelists就表示这种策略组。
一个内存节点最终管理的还是物理内存的page,成员node_mem_map是一个page类型的指针,指向该内存节点所有的page数组。
2中间层——管理区Zone
在介绍节点Node时,我们已经介绍了管理区zone的概念,管理区分为如下几种类型:
enum zone_type {
#ifdef CONFIG_ZONE_DMA
/* DMA内存域,一般为16M,用于ISA */
ZONE_DMA,
#endif
#ifdef CONFIG_ZONE_DMA32
/* 在64位系统中,使用32位地址寻址、适合DMA的内存域 */
ZONE_DMA32,
#endif
/* 可直接映射到内核地址空间的内存区域 */
ZONE_NORMAL,
#ifdef CONFIG_HIGHMEM
/* 内核不能直接映射的内存域 */
ZONE_HIGHMEM,
#endif
/* 可移动内存区域 */
ZONE_MOVABLE,
MAX_NR_ZONES
};
管理区对应的结构体为zone,定义在同一文件中。
/* 内存节点的内存域 */
struct zone {
/* Fields commonlyaccessed by the page allocator */
/* 水线相关字段 */
unsigned long pages_min, pages_low, pages_high;
unsigned long lowmem_reserve[MAX_NR_ZONES];
struct per_cpu_pageset pageset[NR_CPUS];
spinlock_t lock;
struct free_area free_area[MAX_ORDER];
ZONE_PADDING(_pad1_)
/* Fields commonlyaccessed by the page reclaim scanner */
spinlock_t lru_lock;
struct list_head active_list;
struct list_head inactive_list;
unsigned long nr_scan_active;
unsigned long nr_scan_inactive;
unsigned long pages_scanned; /* since last reclaim */
unsigned long flags; /* zone flags, see below */
/* Zone statistics */
atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
int prev_priority;
ZONE_PADDING(_pad2_)
/* Rarely used orread-mostly fields */
wait_queue_head_t * wait_table;
unsigned long wait_table_hash_nr_entries;
unsigned long wait_table_bits;
struct pglist_data *zone_pgdat; /* 该内存域所属的节点*/
/* zone_start_pfn ==zone_start_paddr >> PAGE_SHIFT */
unsigned long zone_start_pfn; /* 该内存域第一个页帧号 */
unsigned long spanned_pages; /* total size, including holes */
unsigned long present_pages; /* amount of memory (excluding holes) */
/*
* rarely used fields:
*/
const char *name; /* 内存域名称*/
} ____cacheline_internodealigned_in_smp;
2.1 padding
首先,该结构体被ZONE_PADDING“分割”成三部分,宏ZONE_PADDING的定义在同一个文件中:
/*
*zone->lock and zone->lru_lock are two of the hottest locks in the kernel.
* So add awild amount of padding here to ensure that they fall into separate
*cachelines. There are very few zonestructures in the machine, so space
* consumptionis not a concern here.
*/
#if defined(CONFIG_SMP)
struct zone_padding {
char x[0];
} ____cacheline_internodealigned_in_smp;
#define ZONE_PADDING(name) struct zone_padding name;
#else
#define ZONE_PADDING(name)
#endif
可见在SMP坏境下,ZONE_PADDING定义了一个zone_padding类型的变量name;而zone_padding本身被定义成一个柔性数组,数组具体的大小会在编译时决定,以保证此前的的部分按照cache line(一般为16个字节)对齐。
为什么要按cache line进行对齐呢?ZONE_PADDING的注释说得很清楚了:因为zone结构体会被频繁访问到,在多核环境下,会有多个CPU同时访问同一个结构体,为了避免彼此间的干扰,必须对每次访问进行加锁。那么是不是要对整个zone加锁呢?一把锁锁住zone中所有的成员?这应该不是最有效的方法。我们知道zone结构体很大,访问zone最频繁的有两个两个场景,一是页面分配,二是页面回收,这两种场景各自访问结构体zone中不同的成员。如果一把锁锁住zone中所有成员的话,当一个cpu正在处理页面分配的事情,另一个cpu想要进行页面回收的处理,却因为第一个cpu锁住了zone中所有成员而只好等待。第二个CPU明知道此时可以“安全的”进行回收处理(因为第一个CPU不会访问与回收处理相关的成员)却也只能干着急。可见,我们应该将锁再细分。zone中定义了两把锁,lock以及lru_lock,lock与页面分配有关,lru_lock与页面回收有关。定义了两把锁,自然,每把锁所控制的成员最好跟锁呆在一起,最好是跟锁在同一个cache line中。当CPU对某个锁进行上锁处理时,CPU会将锁从内存加载到cache中,因为是以cache line为单位进行加载,所以与锁紧挨着的成员也被加载到同一cache line中。CPU上完锁想要访问相关的成员时,这些成员已经在cache line中了。
增加padding,会额外占用一些字节,但内核中zone结构体的实例并不会太多(UMA下只有三个),相比效率的提升,损失这点空间是值得的。
2.2 水位值
一个区域所包含的内存时有限的,如果任凭页面分配程序“予取予求”的话,内存总有耗尽的时刻,等到耗尽时再做补救的话已经为时已晚。所以我们需要未雨绸缪,这内存耗尽之前实施补救措施,也就是唤醒守护进程kswapd来回收一些内存页面。三个水位值pages_min、pages_low、pages_high与守护进程kswapd的“互动”如下图:
关于lowmem_reserve成员,为了避免某些区域的内存分配殆尽(比如ZONE_NORMAL)而另一些区域(比如ZONE_ HIGHMEM)却内存充沛,“旱的旱死涝的涝死”,每个区域都预留一些“压箱底”的内存。
2.3空闲内存
区域中到底有多少可用内存呢?由成员free_area来表示,这是一个structfree_area类型的数组,数组的尺寸MAX_ORDER的定义也在本文件中。如果没有定义CONFIG_FORCE_MAX_ZONEORDER宏的话,MAX_ORDER的值将为11。
/* Freememory management - zoned buddy allocator. */
#ifndefCONFIG_FORCE_MAX_ZONEORDER
#defineMAX_ORDER 11
#else
#defineMAX_ORDER CONFIG_FORCE_MAX_ZONEORDER
#endif
为什么要将可用内存用一个数组来表示呢?这与伙伴系统有关。在内核中,内存管理的工作由伙伴系统来承担,伙伴系统分配的都是 个连续的页面。假定某个系统共有60个物理页,系统运行一段时间后,物理页面的分配情形如下:
左侧的地址空间散布着空闲页,尽管空闲页超过25%,但伙伴系统能够分配的连续页面最大为一页,这就是内存碎片。注意这里的内存碎片只对内核有意义,这种碎片对用户空间没有影响,因为用户空间直接访问的是虚拟地址,通过页表映射到物理地址,即使物理空间不连续,其上的虚拟地址可以是连续的。
如果我们将空闲内存根据其连续页面的大小按照2的n次幂来进行分组,n的取值在[0, MAX_ORDER]闭区间中,则可以有效的减少内存碎片。如果需要分配连续8个页面,则到n=3的组中去找空闲内存,找到了则分配连续的8个页面;如果本组中已经没有空闲页面,则去更高一级n=4的组中去找空闲内存,该组中的空闲内存块都是连续的16个页面,如果该组中有空闲内存,则将空闲内存块一分为二,分成两个连续页面为8的空闲块,一块分配出去,一块并入n=3的组中。在释放内存页时,假定释放的内存为连续的8个页面,则将其归入n=3的空闲页面组中,如果发现该组中某两个内存款互为伙伴,即可将这两个块合并成一个连续16个页面的内存块,并归入到n=4的组中。这就是伙伴系统的工作过程。
struct free_area的定义在同一个文件中:
#define MIGRATE_UNMOVABLE 0
#define MIGRATE_RECLAIMABLE 1
#define MIGRATE_MOVABLE 2
#define MIGRATE_RESERVE 3
#define MIGRATE_ISOLATE 4 /* can't allocate from here */
#define MIGRATE_TYPES 5
struct free_area {
structlist_head free_list[MIGRATE_TYPES];
unsignedlong nr_free;
};
结构体free_area定义了一组队列头,这样,一个管理区的空闲内存就通过两个层次来管理:
空闲内存已经按2的n次幂来进行了分组,对每个组内的内存块为何还要再分组?为了解释这个问题,我们需要知道内核将已经分配的页面按照可移动性分为下列三种:
MIGRATE_UNMOVABLE,不可移动页。页帧在内存中的位置固定,不可以移动,内核分配的大部分页面都属于该类型。
MIGRATE_RECLAIMABLE,可回收页。页帧不能直接移动,但可以删除。其内容可以从某些源重新生成。文件映射对应的内存属于该类。
MIGRATE_MOVABLE,可移动页,页帧可以随意移动,属于用户空间程序的页属于此类,页帧移动后,只需要更新相应的页表即可,用户空间的应用并不会感觉到这些移动。
假定某个连续32页的内存块中,散落着不可移动页(深颜色部分)和可回收页(白色部分)。不可移动页已经被分出去5页(斜线部分)。
此时,虽然可回收页有16页,但最多可分4个连续的页。但如果我们将不可移动页和可回收页分组,如下图,则对于可回收页,最多可分连续的16页,减少了内存碎片。
可见,将内存按照可移动性分组,可以有效减少内存碎片。这就是在2.6.24版本的内核引入的“反碎片”技术的基础。
结构体free_area中的成员nr_free表示该区域空闲页面的总数。
读者可能会有疑问,前面说过内存碎片是对内核而言的,而内核中主要又使用不可移动页面。即使将内存页按移动性分组,可这对解决内核的碎片化又有什么帮助呢?内核仍然在不可移动页上分配,不可移动页上的碎片化并没有改善呀?你的想法是正确的,这里的反碎片技术其实是对用户空间程序有益的。大多数现代CPU都提供了使用巨型页的可能,这种巨型页比普通页大很多,这对内存密集型的应用有好处。用户空间通过页表映射访问内存,使用更大的页(这个页内的地址当然是连续的),则“地址转换/查找缓冲区”只需处理较少的项,并且可以降低TLB缓存(为了加快页面映射的速度,并不是每次都从内存中访问页面映射目录和页面映射表,而是将它们装入高速缓存中缓冲起来,这部分高速缓存称为TLB,即“地址转换/查找缓冲区”(Translation Lookaside Buffers))失效的可能性。而分配巨型页,就需要更多的连续内存页。用户空间的应用程序一般在可移动或者可回收内存页上分配,将内存按移动性分组后,我们就可以利用这种移动性,将小块空闲内存合并成大块空闲内存,给分配巨型页提供了可能。
如果内核无法满足针对某种移动性的分配请求,会怎么样?这与我们在Node定义时讨论的备选区的问题类似,内核的解决办法也是提供一个备选列表。其定义如下,其表达的意图不言自明。
<mm/page_alloc.c>
static intfallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
[MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE},
[MIGRATE_RECLAIMABLE]= { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE},
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE,MIGRATE_UNMOVABLE,
MIGRATE_RESERVE },
[MIGRATE_RESERVE] = { MIGRATE_RESERVE, MIGRATE_RESERVE,
MIGRATE_RESERVE}, /* Never used */
};
zone中其他的成员的含义请参考注释。
3最底层——物理页帧Page
物理页帧是物理内存的最小管理单元,其对应的抽象为page,结构体定义如下:
struct page {
/*用于描述页的属性。如PG_locked */
unsignedlong flags;
/* 使用计数,表示内核中引用该页的次数 */
atomic_t_count; /* Usage count, see below. */
union {
/*
* 如果该页映射到用户空间虚拟地址上,则表示映射到页表pte的次数
* 每增加一个使用者,计数器加1
*/
atomic_t_mapcount;
/* 如果是内核slab使用的页,则表示其中的slab对象数目 */
unsignedint inuse;/* SLUB: Nr of objects */
};
union {
struct {
/*
* 私有数据指针。
* 如果页位于交换缓存,则指向存储swp_entry_t结构
*/
unsignedlong private;
structaddress_space *mapping;
};
struct kmem_cache *slab; /* SLUB: Pointer to slab */
struct page *first_page; /* Compound tail pages */
};
union {
pgoff_tindex; /* Our offset within mapping.*/
void*freelist; /* SLUB: freelist req. slablock */
};
structlist_head lru; /*用于页面换出的链表,可能链接到活动页链表和不活动页链表 */
#if defined(WANT_PAGE_VIRTUAL)
void*virtual; /* Kernel virtual address(NULL if not kmapped,
ie. highmem) */
#endif
};
由于一个page可能通过页表映射到了用户的虚拟地址空间中,也可能在内核中被slab分配器管理,所以结构体的定义中有很多的联合union。slab分配器的工作过程比较复杂,留待以后分析。后面的讲解将跳过slab分配相关的内容。
mapping为address_space类型的指针,在页面换入换出时会详细讲到。
当页面的内容来自一个文件时(比如mmap映射,或者时从交换文件中换入),index代表着该页面在文件中的序号;当页面的内容换出到交换设备上,但还保留着内容作为缓冲室,index指向了页面的去向。
为了便于后文中的情景分析,这里将2.4版本内核中page结构体的定义展示如下:
/*
* Try tokeep the most commonly accessed fields in single cache lines
* here(16 bytes or greater). This ordering should be particularly
*beneficial on 32bit processors.
*
* Thefirst line is data used in page cache lookup, the second line
* is usedfor linear searches (eg. clock algorithm scans).
*/
typedef struct page {
structlist_head list;
structaddress_space *mapping;
unsignedlong index;
structpage *next_hash;
atomic_tcount;
unsignedlong flags; /* atomic flags, some possibly updated asynchronously */
structlist_head lru;
unsignedlong age;
wait_queue_head_t wait;
structpage **pprev_hash;
structbuffer_head * buffers;
void*virtual; /* nonNULL if kmapped */
struct zone_struct *zone;
} mem_map_t
该版本的实现中,page有两个成员next_hash和pprev_hash,该成员用来将page链到某个哈希表中。
page就像是物理页帧的户口,每一个物理页帧都对应一个page结构。如果一个物理页面没有对应的page结构,它就成了“黑户”了,系统就无法看到它,也就无法对它进行管理。系统在初始化时,会根据物理内存的大小建立一个全局的page结构体数组mem_map,作为物理页面的“户口簿”,里面的每一个元素代表一个物理的页帧,而数组的下标就是物理page的逻辑编号。
物理内存管理中的这三层抽象,示意如下: