Q1: __free_one_pages의 다소 복잡한 이유? A: mm/page_alloc: prevent merging between isolated and other pageblocks 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: memory unplug

Intro 커널 코드를 살펴보면, 종종 "trace_" 접두사가 붙은 함수들을 살펴볼 수 있다. 해당 함수가 어떤 식으로 구현되어 있는지 살펴보려고 태그를 따라가려 하면 태그를 찾을 수 없을 것이다. 만약 해당 함수에 대한 간략한 설명이 있다면 디버깅을 위한 함수 또는 TracePoint를 위한 함수라고 설명되어 있을 것이다. 설명과 같이 trace 함수들은 TracePoint에 의해 정의된 함수들이며, 이름 그대로 커널 내부 특정한 위치에 "Trace Point"를 제공하는 hook point이며 매크로를 통해 선언된다. 이 뿐만 아니라 TracePoint는 다른 tracing/profile 서브 시스템과 연관 관계가 존재한다. 그렇기 때문에 해당 포스트에서는 Trace Point 그 자체 뿐만 아니라 다른 서브 시스템(ftrace, perf)과의 연결 고리에 대해 알아보도록 하겠다. TracePoint Trace Point는 Mathieu De

Background 현재 CPU의 발전 흐름은, CPU의 clock의 속도를 늘리는 방향이 아니라 코어의 개수를 늘려 throughput 늘리는 방향으로 진행되고 있다. core의 수가 늘어나면서 memory에 대한 높은 bandwith이 요구된다. 하지만 아래와 같이 North bridge에 단일 memory controller로 구성된 시스템이라면 North bridge가 병목 구간이 될 수 있다. 이와 같은 문제를 해결하기 위해, CPU마다 memory controller 통합하고 local Ram을 연결하여 전체적인 bandwidth을 증가시킬 수 있다. 서로 다른 다이 또는 코어와의 커뮤니케이션은 데이터 버스로 이루어진다. 위의 예시에서 서로 다른 다이들은 inter connection controller로 연결되어 있다. 만약 1번 die에서 2번 die에 위치한 메모리에 접근하려면 interconnection controller을 통해

ftrace(function+tracer)는 커널 내부에서 어떤 일이 일어나는 지 확인하거나, 디버깅 혹은 성능 분석에 많이 사용되는 기능이다. 아래의 그림은 function_graph tracer을 이용하여 call chain을 확인한 것이다. 많은 다른 포스팅에서 ftrace를 소개하고 사용법도 잘 설명하기 때문에 해당 포스트에서는 구체적인 사용법보다는 원리에 초점을 맞춘다. Simple usage ftrace은 package manager을 통해 설치하는 유틸리티가 아니고, 커널에 내장되어 있는 기능이다. 사용자가 ftrace를 다루기 위해서는 debugfs을 이용해야 한다. 대부분의 배포판들은 /sys/kernel/debug 경로에 debugfs를 마운트한다. 아래의 커맨드와 같이 debugfs가 어디에 마운트되어 있는지 확인할 수도 있다. 만약 마운트되어 있지 않다면 직접 마운트 하면 된다. /sys/kernel/tracing 경로로 이

일반적으로 메모리를 할당 받을 때는 buddy 시스템을 통해 페이지를 할당 받는다. 다양한 anti-fragmentation 기법이 적용된 buddy 시스템이라도 부팅 후에는 지속으로 단편화가 발생하고, 따라서 연속된 큰 메모리를 할당하기 어려워지게 된다. 이러한 문제를 Contiguous Memory Allocator(CMA)가 해결하여 시스템 부팅 후에도 연속된 큰 메모리를 할당할 수 있도록 한다. 좀 더 구체적인 동기는 contiguous.c 파일 상단부에 기술되어 있다. 간단히 요약하면, 임베디드 시스템에서, camera나 video coder들은 동작을 위해 큰 크기의 버퍼가 필요할 때가 있다. 예를 들어, full HD 프레임이라면 6MB 이상의 버퍼가 필요한데 이 버퍼를 할당하기 위해 slab, buddy 시스템을 이용하는 것은 비효율적이다. 아래의 디바이스 트리처럼, 메모리 공간을 분리하여 디바이스만 사용하도록 reserve 할 수