linux内核冷热页,Linux中的冷热页机制简述

小鱼儿 2023-01-21 09:27 4阅读 0赞

什么是冷热页？

在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的命中率。

冷热页的数据结构

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)。若需要热页，则从链表头取下一页(此页最“热”)；若需要冷页，则从链表尾取下一页(此页最“冷”)。

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

/\* \* 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 don't 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; \}

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