티스토리 뷰

__free_one_page
- 여기서 해제시 머지하는 부분은 이해가 됐음,
- *다만 max_order, MAX_ORDER, pageblock_order 의 이해가 명확하지 않음*
- buddy 할당자에서 struct page 의 Privatge 은 order 값으로 사용. (2^order 사이즈)
- 상위 슬롯에서 버디를 발견하면 cold (뒤로 넣는다)

 

static inline int page_is_buddy(struct page *page, struct page *buddy,
unsigned int order) -> 이게 buddy 만 실제 buddy 로 Free 인지 검사하기 때문

 

┌────────────────────┐
└──▲──────────▲──────┘
┌──┼──────┐┌──┼──────┐
└──▲───▲──┘└──▲───▲──┘
┌──┼─┌─┼──┐┌──┼─┌─┼──┐
└────└────┘└────└────┘



여기에서 사용중이지 않고 버디 시스템에 free 된 상태인게 검사 됐구나

static inline int PageBuddy(struct page *page)
{
return atomic_read(&page->_mapcount) == PAGE_BUDDY_MAPCOUNT_VALUE;
}

per-cpu 페이지 프레임 캐시 (pcp)

 

per_cpu_pageset *pcp; -> per_cpu_pages 를 가짐. list, batch, high

- 각 존 별로, per cpu page frame cahce 와 buddy allocator 를 가짐
- batch : 캐시에 한번에 가져올 페이지 수, 혹은 돌려줄 수
- free 시 남아있는 page 가 high 보다 크면 batch 만큼 돌려줌
- migration  타입을 round robin 으로 돌면서 빼줌
- page block 과 Page 의 migrate type 의 차이, page block 과 page 의 차이 (물리, 가상 의차이?)

on_each_cpu_mask -> 각 cpu 에서 실행되는듯 보임. smp_processor_id 로 cpu 를 얻는걸 보니

 

NUMA


각 존은 최대 4개까지 구성 가능 (ZONE_DMA,DMA32,NORMAL,HIGH,MOVABLE)
태스크는 노드를 사용할때 NUMA 메모리 정책을 사용.

특정 노드에서 특정 존에서 out of memory 가 나는 경우, 다른 zone 에서 할당을 받음. 이를 fallback 이라고 하고, 이때 사용하는 존 list 를 zonelist order 로 우선순위를 관리, zone list 는 fallback 용 zone 을 관리한다

노드 우선 -> 노드 먼저 정렬 & 존 정렬 (같은 노드 할당 가능성) / 존 우선 -> 존 정렬 & 노드 정렬 (같은 존 할당 가능성)
zone->node_order 에서 사용

NUMA 의 zonelists
zonelists[0] : 전체 노드용 / zonelists[1] : 현재 노드용 

ZONE_MOVABLE: 버디 시스템의 페이지 단편화를 막기 / 핫플러그 지원 위한 영역

pg_data_t 노드의 정보담겨있음

댓글