小知识:Linux中的冷热页机制简述

什么是冷热页?

在Linux Kernel的物理内存管理的Buddy System中,引入了冷热页的概念。冷页表示该空闲页已经不再高速缓存中了(一般是指L2 Cache),热页表示该空闲页仍然在高速缓存中。冷热页是针对于每CPU的,每个zone中,都会针对于所有的CPU初始化一个冷热页的per-cpu-pageset. 

为什么要有冷热页?

作用有3点:

 Buddy Allocator在分配order为0的空闲页的时候,如果分配一个热页,那么由于该页已经存在于L2 Cache中了。CPU写访问的时候,不需要先把内存中的内容读到Cache中,然后再写。如果分配一个冷页,说明该页不在L2 Cache中。一般情况下,尽可能用热页,是容易理解的。什么时候用冷页呢?While allocating a physical page frame, there is a bit specifying whether we would like a hot or a cold page (that is, a page likely to be in the CPU cache, or a page not likely to be there). If the page will be used by the CPU, a hot page will be faster. If the page will be used for device DMA the CPU cache would be invalidated anyway, and a cold page does not waste precious cache contents. 

简单翻译一下:当内核分配一个物理页框时,有一些规范来约束我们是分配热页还是冷页。当页框是CPU使用的,则分配热页。当页框是DMA设备使用的,则分配冷页。因为DMA设备不会用到CPU高速缓存,所以没必要使用热页。

 Buddy System在给某个进程分配某个zone中空闲页的时候,首先需要用自旋锁锁住该zone,然后分配页。这样,如果多个CPU上的进程同时进行分配页,便会竞争。引入了per-cpu-set后,当多个CPU上的进程同时分配页的时候,竞争便不会发生,提高了效率。另外当释放单个页面时,空闲页面首先放回到per-cpu-pageset中,以减少zone中自旋锁的使用。当页面缓存中的页面数量超过阀值时,再将页面放回到伙伴系统中。

使用每CPU冷热页还有一个好处是,能保证某个页一直黏在1个CPU上,这有助于提高Cache的命中率。

冷热页的数据结构

?
1
2
3
4
5
6
7
8
struct per_cpu_pages {
int count;    // number of pages in the list
int high;    // high watermark, emptying needed
int batch;    // chunk size for buddy add/remove
// Lists of pages, one per migrate type stored on the pcp-lists
每个CPU在每个zone上都有MIGRATE_PCPTYPES个冷热页链表(根据迁移类型划分)
struct list_head lists[MIGRATE_PCPTYPES];
};

在Linux中,对于UMA的架构,冷热页是在一条链表上进行管理。热页在前,冷页在后。CPU每释放一个order为0的页,如果per-cpu-pageset中的页数少于其指定的阈值,便会将释放的页插入到冷热页链表的开始处。这样,之前插入的热页便会随着其后热页源源不断的插入向后移动,其页由热变冷的几率便大大增加。

怎样分配冷热页

在分配order为0页的时候(冷热页机制只处理单页分配的情况),先找到合适的zone,然后根据需要的migratetype类型定位冷热页链表(每个zone,对于每个cpu,有3条冷热页链表,对应于:MIGRATE_UNMOVABLE、MIGRATE_RECLAIMABLE、MIGRATE_MOVABLE)。若需要热页,则从链表头取下一页(此页最“热”);若需要冷页,则从链表尾取下一页(此页最“冷”)。 

分配函数(关键部分已添加注释):

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
/*
* Really, prep_compound_page() should be called from __rmqueue_bulk(). But
* we cheat by calling it from here, in the order > 0 path. Saves a branch
* or two.
*/
static inline
struct page *buffered_rmqueue(struct zone *preferred_zone,
struct zone *zone, int order, gfp_t gfp_flags,
int migratetype)
{
unsigned long flags;
struct page *page;
//分配标志是__GFP_COLD才分配冷页
int cold = !!(gfp_flags & __GFP_COLD);
again:
if (likely(order == 0)) {
struct per_cpu_pages *pcp;
struct list_head *list;
local_irq_save(flags);
pcp = &this_cpu_ptr(zone->pageset)->pcp;
list = &pcp->lists[migratetype];
if (list_empty(list)) {
//如果缺少页,则从Buddy System中分配。
pcp->count += rmqueue_bulk(zone, 0,
pcp->batch, list,
migratetype, cold);
if (unlikely(list_empty(list)))
goto failed;
}
if (cold)
//分配冷页时,从链表尾部分配,list为链表头,list->prev表示链表尾
page = list_entry(list->prev, struct page, lru);
else
//分配热页时,从链表头分配
page = list_entry(list->next, struct page, lru);
//分配完一个页框后从冷热页链表中删去该页
list_del(&page->lru);
pcp->count–;
} else {//如果order!=0(页框数>1),则不从冷热页链表中分配
if (unlikely(gfp_flags & __GFP_NOFAIL)) {
/*
* __GFP_NOFAIL is not to be used in new code.
*
* All __GFP_NOFAIL callers should be fixed so that they
* properly detect and handle allocation failures.
*
* We most definitely dont want callers attempting to
* allocate greater than order-1 page units with
* __GFP_NOFAIL.
*/
WARN_ON_ONCE(order > 1);
}
spin_lock_irqsave(&zone->lock, flags);
page = __rmqueue(zone, order, migratetype);
spin_unlock(&zone->lock);
if (!page)
goto failed;
__mod_zone_page_state(zone, NR_FREE_PAGES, -(1 << order));
}
__count_zone_vm_events(PGALLOC, zone, 1 << order);
zone_statistics(preferred_zone, zone, gfp_flags);
local_irq_restore(flags);
VM_BUG_ON(bad_range(zone, page));
if (prep_new_page(page, order, gfp_flags))
goto again;
return page;
failed:
local_irq_restore(flags);
return NULL;
}

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持服务器之家。

声明: 猿站网有关资源均来自网络搜集与网友提供,任何涉及商业盈利目的的均不得使用,否则产生的一切后果将由您自己承担! 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除,制止非法恶意传播,不对任何下载或转载者造成的危害负任何法律责任!也请大家支持、购置正版! 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报,会员发帖仅代表会员个人观点,并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络,如有侵权烦请发送邮件至:2697268773@qq.com进行处理。
建站知识

小知识:Nginx 防止被域名恶意解析的办法

2023-4-21 4:38:42

建站知识

小知识:详解nginx 代理多个服务器(多个server方式)

2023-4-21 4:48:01

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索