Q1: __free_one_pages의 다소 복잡한 이유?
A:
CMA 타입과, ISOLATE 타입의 블록 병합 문제 현상 존재.
기존에는, free되는 페이지의 migration type을 보고, MAX_ORDER 까지의 병합을 허락한다.
하지만, isolation은 atmoic하게 pageblock의 속성을 변경하는게 아니라, 순차적으로 변경한다.
zone에 isolated된 페이지가 있는지 확인하고, target과 buudy의 block의 속성이 다르고, 하나라도 isolated 속성이라면 merging을 중단하는 로직을 추가한다. 그렇지 않다면 IC, CI 일 때, C에 free pages가 일어나면, isolated pageblock이 병합될 수 있다.
Q2: isolation type?
A:
freelist에 등록된 페이지라도 isolated되었다면 할당되지 않도록 하게 만드는 feature. free된 페이지가 곧 바로 isolated block으로 들어가도록 하여 사용되지 않도록 한다.
pagblock mobility에 isolation 타입을 추가, alloc에서 isolation의 블록을 steal하지 않게 구성하면 된다.
start_isolate_page_range(start, end)를 통해 movable page block을 isolated 속성으로 변경한다.
이 기능은 메모리 unplug를 염두에 두고 구현되었다. unplug는 hotremove를 의미하는가?
Q3:no_map인 region도 __free_pages_core에서 호출되어 버디에 등록되는 게 아닌가?
A:
memblock에서 reserved된 페이지들은, buddy system에 등록되지 않는다. memblock iterating 매크로에서 reserved된 영역과 nomap 영역은 스킵된다.
Q4: PageDoubleMap?
Pass:
이를 이해하기 위해서는 THP에 대해 이해 필요할 듯...
Q5: Capture Control?
A:
Q6: pageblock의 단위는 pmd에 맞춘 듯한데 의도한 것?
A:
pmd 단위의 fragmentation을 방지하여, huge page 할당에 도움이 되도록 한다(추측)?
Q7: numa_node_id 매크로 구현이 특정 매크로(CONFIG_USER_PERCPU_NUMA_NODE_ID)에 종속적인 것 아닌가? 해당 옵션을 끌 수도 있나?
A:
해결 안됨...
Q8: PF_MEMALLOC_PIN (pinning?)
A:
PF_MEMLALLOC_NOCMA는 allocator가 CMA 영역의 페이지를 반환하지 않도록하는 task 플래그이다.
Q9: cpuset(cgroup v1)?
A:
HARDWALL cpu
Q10: should_fail_alloc_page?
A:
kernel_parameter 또는 debugfs를 통해 인위적으로 fault를 유발할 수 있도록하는 기능.
falut injection 시스템이 존재하며 거기서 다양한 시스템에서 인위적인 fault를 injection할 수 있다.
Disscussion:
static_key를 통해 on/off를 하는 것이 더 효율적이지 않은가?
개념 자체는 오래되었고, 유지 보수할 만한 부분이 많은 것 같다.
따로 fault injection 기능만 다루는 글을 작성해도 괜찮을 것 같다.
Q11: ALLOC_NOFRAGMENT
A:
__rmqueue_fallback 함수에서 min_order을 page_block 단위로 설정. 최소 min_order을 page_block으로 설정하여 한 쪽 zone(Normal)만 단편화가 심하고, DMA32는 심하지 않은 현상을 완화하려는 노력
Problem:
mm/page_alloc.c:4011 다른 node의 zone이라면?
Q11.1: 왜 ZONE_DMA32에 종속적인 것일까?
A:
/*
* The restriction on ZONE_DMA32 as being a suitable zone to use to avoid
* fragmentation is subtle. If the preferred zone was HIGHMEM then
* premature use of a lower zone may cause lowmem pressure problems that
* are worse than fragmentation. If the next zone is ZONE_DMA then it is
* probably too small. It only makes sense to spread allocations to avoid
* fragmentation between the Normal and DMA32 zones.
*/
Q12: spread_dirty_page? 왜 dirty page 밸런싱이 필요한가?
A:
관련 패치:
zone 간 spreading을 하지 않으면, 하나의 zone에 dirty 페이지가 몰리고(다른 zone은 비교적 clean한 상태인체로) kswapd가 zone의 lru의 dirty 페이지를 write하는 상황이 빈번해진다.
major 파일 시스템은 write request를 무시해서 상황은 더 악화된다? 이 경우 zone이 balance되는 방법을 막아버리기 때문이다.
dirty zone balacing은 lru가 node로 변경되면서, 그 의미를 제대로 살리지 못하고 있다.
사실 상, spread_dirty_pages는 node간 dirty 밸런싱을 한다.
idea:
node mask를 만들 때, setup되어 있는 node에 대해 node_dirty_ok를 확인하고 dirty한 경우, node_mask에서 내리자.
이러면 좀 더 세련되게 node를 skip할 수 있다.
bitmap을 새로 할당받아야 하나? 그 코스트가 더 클 것 같은데?
Q13: Fair zone allocation이 더 이상 유효한가?
A:
Fair zone allocation은 LRU가 zone→ Node로 변경되어서 removed 되었다. 그렇다면 GFP_WRITE에 있는 설명은 잘못된 것 아닌가? 해당 플래그는 dirty page balancing의 의미를 가진 것 아닌가?
Comments