[ARM] Cortex-A 페이징

ARM Cortex-A 페이징에 대해서 잘 적혀있는 글 발견!
설명하면서 쓴 단어의 정의들도 정확하다. 설명도 간략하면서 쉽게 되어 있다.

http://kth3321.blogspot.kr/search?q=ARM+Cortex-A+%ED%8E%98%EC%9D%B4%EC%A7%95 

아참, 본문의 내용 중 예제에 Offset에 따른 물리 주소를 그저 Offset을 더하는 것으로 설명되어져 있는데, 이 부분은 잘못된 것으로 보인다. 실제로는 32비트 주소 값 혹은 pgd/pte 의 주소+a를 갖고 있으므로 Base + Offset * 4(=32 bits) 의 물리 주소를 참조한다.

[Linux:Kernel] AArch64 리눅스의 메모리 배치

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/memory.txt

     AArch64 리눅스의 메모리 배치
     ============================

Author: Catalin Marinas <catalin.marinas@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 20 February 2012

이 문서는 AArch64 리눅스 커널이 사용하는 가상 메모리 배치를 설명합니다.
이 아키텍처는 4KB 페이지 크기의 4단계 변환 테이블과 64KB 페이지 크기의
3단계 변환 테이블을 허용합니다.

AArch64 리눅스는 유저와 커널 양 쪽 모두 39비트 (512GB) 가상 주소를 허용하는
4KB 페이지 설정의 3단계 변환 테이블을 사용합니다. 64KB 페이지는 오직
2단계 변환 테이블이 사용되지만 메모리 배치는 같습니다.

유저 주소는 63:39 비트가 0으로 셋팅되는 반면, 커널 주소는 같은 곳의 비트에
1로 셋팅됩니다. TTBRx 선택은 가상 주소의 비트 63에 의해 결정됩니다.
swapper_pg_dir은 오직 커널 (전역) 맵핑만 포합하는 반면,
유저 pgd는 오직 유저 (비전역) 맵핑만 포함합니다. swapper_pgd_dir 주소는
TTBR1으로 쓰여지고, TTBR0로 절대 쓰여지지 않습니다.


4KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 0000007fffffffff 512GB 유저

ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc

ffffffbbffff0000 ffffffbbffffffff  64KB [guard page]

ffffffbc00000000 ffffffbdffffffff   8GB vmemmap

ffffffbe00000000 ffffffbffbbfffff  ~8GB [guard, 추후 vmmemap]

ffffffbffa000000 ffffffbffaffffff  16MB PCI I/O 공간

ffffffbffb000000 ffffffbffbbfffff  12MB [guard]

ffffffbffbc00000 ffffffbffbdfffff   2MB 고정 맵핑

ffffffbffbe00000 ffffffbffbffffff   2MB [guard]

ffffffbffc000000 ffffffbfffffffff  64MB 모듈들

ffffffc000000000 ffffffffffffffff 256GB 커널 논리 메모리 맵


64KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 000003ffffffffff   4TB 유저

fffffc0000000000 fffffdfbfffeffff  ~2TB vmalloc

fffffdfbffff0000 fffffdfbffffffff  64KB [guard page]

fffffdfc00000000 fffffdfdffffffff   8GB vmemmap

fffffdfe00000000 fffffdfffbbfffff  ~8GB [guard, 추후 vmmemap]

fffffdfffa000000 fffffdfffaffffff  16MB PCI I/O 공간

fffffdfffb000000 fffffdfffbbfffff  12MB [guard]

fffffdfffbc00000 fffffdfffbdfffff   2MB 고정 맵핑

fffffdfffbe00000 fffffdfffbffffff   2MB [guard]

fffffdfffc000000 fffffdffffffffff  64MB 모듈들

fffffe0000000000 ffffffffffffffff   2TB 커널 논리 메모리 맵


4KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |         |         |         |         |
 |                 |         |         |         |         v
 |                 |         |         |         |   [11:0]  페이지 내의 오프셋
 |                 |         |         |         +-> [20:12] L3 인덱스
 |                 |         |         +———–> [29:21] L2 인덱스
 |                 |         +———————> [38:30] L1 인덱스
 |                 +——————————-> [47:39] L0 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1


64KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |    |               |              |
 |                 |    |               |              v
 |                 |    |               |            [15:0]  페이지 내의 오프셋
 |                 |    |               +———-> [28:16] L3 인덱스
 |                 |    +————————–> [41:29] L2 인덱스 (38:29 만 사용)
 |                 +——————————-> [47:42] L1 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1

KVM을 사용할 때, 하이퍼바이저는 커널 페이지를 EL2에서 커널 VA로부터 고정된
오프셋(커널 VA의 상위 24비트를 0으로 셋팅한)에 맵핑합니다:

시작 크기 용도
———————————————————————–
0000004000000000 0000007fffffffff 256GB HYP 내에서 맵핑된 커널 객체

[Linux:Kernel] AArch64 리눅스 부팅(AArch64 Linux Booting)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/booting.txt

AArch64 리눅스 부팅

===================

Author: Will Deacon <will.deacon@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 07 September 2012

이 문서는 Russell King의 ARM 부팅 문서에 기초하고 AArch64 리눅스 커널의
모든 공개 릴리즈와 연관됩니다.

AArch64 예외 모델은 몇 개의 예외 단계(EL0 – EL3)으로, 그 중 EL0와 EL1은
시큐어와 논-시큐어 구성을 가지는 것으로 구성되어 있습니다. EL2는
하이퍼바이저 단계이고 논-시큐어 모드에서만 존재합니다. EL3는 가장 높은
단계이고, 시큐어 모드에서만 존재합니다.

이 문서의 목적에 따라, 우리는 ‘부트 로더’ 용어를 간단히 리눅스 커널로
제어를 넘기기 전에 CPU(들) 상에서 실행되는 모든 소프트웨어로 정의하여
사용할 것입니다. 이것은 시큐어 모니터와 하이퍼바이저 코드를 포함할 것이고,
또는 최소 부팅 환경을 준비하기 위한 한 줌의 명령들이 될 수도 있습니다.

기본적으로, 부트 로더는 다음을 (최소한) 제공해야 합니다:

1. RAM을 셋업하고 초기화
2. 디바이스 트리를 셋업
3. 커널 이미지를 압축 해제
4. 커널 이미지를 호출
1. RAM을 셋업하고 초기화
————————

요구 사항: 필수

부트 로더는 커널이 시스템 상의 임시 데이터 저장 공간으로 사용할 모든
RAM을 찾아서 초기화할 것으로 여겨집니다. 이는 머신 의존적인 방법으로
수행됩니다. (자동으로 모든 RAM의 크기를 재고 위치시키는데 내부
알고리즘을 사용하거나, 머신 안의 RAM에 대한 지식을 사용하거나, 또는
부트 로더 설계자가 맞춰 보는 다른 방법을 사용할 수도 있습니다.)
2. 디바이스 트리를 셋업
———————–

요구 사항: 필수

디바이스 트리 조각 (dtb)는 8 바이트 경계로 커널 이미지의 시작으로부터
512 메가 바이트 내에, 그리고 2 바이트 경계에 걸치지 않도록 위치해야만
합니다. 이것은 커널이 초기 페이지 내이블 내의 하나의 섹션 맵핑을 사용해서
조각을 맵핑할 수 있도록 해줍니다.
3. 커널 이미지를 압축 해제
————————–

요구 사항: 선택

AArch64 커널은 현재 압축 해제기를 제공하지 않고, 그래서 압축된 Image 타겟
(예를 들면, Image.gz)이 사용된다면 부트 로더에 의한 압축 해제
(gzip, 기타 등)를 요구합니다. 이 요구 사항을 구현하지 않은 부트로더들을
위해서 압축되지 않은 Image 타겟이 현재 대신 이용 가능합니다.
4. 커널 이미지를 호출
———————

요구 사항: 필수

압축 해제된 커널 이미지는 다음과 같은 64바이트 헤더를 포함합니다:

  u32 code0;
/* 실행 가능 코드 */
  u32 code1; /* 실행 가능 코드 */
  u64 text_offset; /* 이미지 로딩 오프셋 */
  u64 res0 = 0; /* 여분으로 예약 */
  u64 res1 = 0; /* 여분으로 예약 */
  u64 res2 = 0; /* 여분으로 예약 */
  u64 res3 = 0; /* 여분으로 예약 */
  u64 res4 = 0; /* 여분으로 예약 */
  u32 magic = 0x644d5241; /* 매직 넘버, 리틀 엔디언, “ARM\x64” */
  u32 res5 = 0;       /* 여분으로 예약 */
헤더 설명:

– code0/code1 은 stext로의 뜀을 책임집니다.
– EFI를 통해 부팅할 때, code0/code1은 초기에 건너 뜁니다. res5는
  PE 헤더로의 offset이고, PE 헤더는 EFI 진입 포인트(efi_stub_entry)를
  가집니다. 그 코드 조각이 작업을 끝내면, 보통의 부팅 프로세스를 재개하기
  위해서 code0 로 점프합니다.
  
이미지는 시스템 RAM의 시작으로부터 지정된 오프셋(현재는 0x80000)에
위치하고, 거기서 호출되어야만 합니다. 시스템 RAM의 시작은 2MB로 정렬되어져
있어야 합니다.

커널로 점프하기 전에, 다음 조건을 만족해야만 합니다:

– 모든 DMA 가능 장치들을 중지시켜 메모리가 가짜 네트워크 패킷이나
  디스크 데이터로 인해 깨지지 않도록 하세요. 이것은 많은 디버깅 시간을
  절약시켜 줄 것입니다.
  
– 주요 CPU 일반-목적(general-purpose) 레지스터 셋팅
  x0 = 시스템 RAM 내의 디바이스 트리 조각(dtb)의 물리 주소
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)  
  
– CPU 모드
  모든 형태의 인터럽트는 PSTATE.DAIF(Debug, Serror, IRQ 그리고 FIQ)로
  마스킹되어져야 합니다.
  CPU는 EL2(가상화 확장에 접근하기 위해서 추천함) 또는 논-시큐어 EL1 에
  있어야 합니다.

– 캐시, MMU
  MMU는 반드시 꺼져야 합니다.
  명령 캐시는 켜지거나 꺼져 있을 수 있습니다.
  로딩된 커널 이미지에 해당하는 주소 범위는 PoC로 깨끗해야 합니다.
  시스템 캐시나 켜진 캐시와 연관된 다른 마스터들의 존재 안에서,
  이것은 보통, 셋/웨이 연산보다는 VA에 의한 캐시 관리를 필요로 합니다.
  VA 연산에 의한 구조화된 캐시 관리를 준수하는 시스템 캐시는 설정되어져야
  하고, 켜지게 될 것 입니다.
  VA 연산에 의한 구조화된 캐시 관리를 따르지 않는(권장하지 않음) 시스템
  캐시는 설정되고 꺼져야만 합니다.

– 구조화된 타이머
  CNTFRQ는 반드시 타이머 주기로 프로그램되어야 하고, CNTVOFF는 모든
  CPU들의 일관된 값으로 프로그램되어야 합니다. 만약 EL1에서 커널로
  진입한다면, CNTHCTL_EL2는 반드시 셋팅된 EL1PCTEN(비트 0)을 가져야 합니다.

– 연관성
  커널에 의해 부팅될 모든 CPU들은 커널로의 진입 상의 같은 연관 도메인의
  일부가 되어야 합니다. 이것은 각 CPU 상의 관리 연산의 수신을 켜는
  ‘구현에 따라 정의된’ 초기화를 요구할 것입니다.
  
– 시스템 레지스터
  커널이미지가 진입하는 그 예외 레벨에서 모든 쓰기 가능한 구조화된 시스템
  레지스터들은 ‘알려지지 않은’ 상태 내의 실행을 막기 위해서 더 높은 예외
  레벨에서 소프트웨어에 의해 초기화되어야만 합니다.

위에 쓰여진 CPU 모드, 캐시, MMU, 구조화된 타이머, 연관성과 시스템 레지스터들에
대한 요구사항은 모든 CPU에 적용됩니다. 모든 CPU는 같은 예외 레벨 안에서
커널로 진입해야 합니다.

부트로더는 각 CPU가 다음과 같은 관례로 커널로 진입할 것으로 생각합니다:

– 주 CPU는 커널 이미지의 첫 명령으로 직접 점프해야만 합니다. 이 CPU에 의해
  넘겨진 디바이스 트리 조각은 각 CPU 노드의 ‘enable-method’ 프로퍼티를
  포함해야만 합니다. 지원되는 enable-method 들은 아래에서 설명합니다.

  부트로더는 이들 디바이스 트리 프로퍼티를 생생하고 커널 진입보다 먼저
  조각 안에 그들을 끼워 넣을 것입니다.

– “spin-table” enable-method 의 CPU들은 그들의 cpu 노드 내에
  하나의 ‘cpu-release-addr’ 프로퍼티를 가져야 합니다. 이 프로퍼티는
  자연스럽게 정렬된 64비트의 0으로 초기화된 메모리 위치를 나타냅니다.

  이 CPU들은 예약된 영역 안에 포함되어야만 하는, 그들의 cpu-release-addr
  위치를 폴링하는 (디바이스 트리 안의 /memreserve/ 영역에 의해 커널로
  전달되는) 메모리의 예약된 영역 안의 커널 밖에서 돌아야 합니다.
  wfe 명령은 비지-루프(busy-loop)의 부하를 줄이기 위해서 추가될 것이고,
  sev는 주 CPU에 의해 일어날 것입니다. cpu-release-addr에 의해
  가리켜지는 위치를 읽는 것이 0이 아닌 값을 반환할 때, 그 CPU는 이 값으로
  점프해야 합니다. 그 값은 하나의 64비트 리틀 엔디언 값으로 쓰여질
  것이므로 CPU들은 읽은 값을 그리로 점프하기 전에 그들 원래의 엔디언으로
  변환해야 합니다.

– “psci” enable method의 CPU들은 커널의 밖(즉, memory 노드 안에 커널로
  기술된 메모리의 그 영역 밖, 또는 디바이스 트리 안의 /memreserve/ 영역에
  의해 커널로 기술된 메모리의 예약된 영역 안)에 남아 있어야 합니다.
  커널은 커널 내로 CPU들을 가져오기 위해서 ARM DEN 0022A
  (“Power State Coordination Interface System Software on ARM processors”)
  문서 안에 설명된 것처럼 CPU_ON 호출들을 일으킬 것입니다.
  
  디바이스 트리는 하나의 ‘psci’ 노드를
  Documentation/devicetree/bindings/arm/psci.txt 안에 설명된대로
  포함해야만 합니다.

– 두번째 CPU 일반-목적 레지스터 셋팅
  x0 = 0 (차후 용도를 위해 예약)
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)

[Android] “Running Android with low RAM” 의 Kernel Configuration

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.
 

원문: http://source.android.com/devices/low-ram.html
번역: 양정석<dasomoli@gmailREMOVETHIS.com>(근데 원래 혼자 보려던 거라 이상한 거 많음;;)

커널 설정


직접 회수(Direct reclaim)를 줄이기 위한 커널/ActivityManager 튜닝

직접 회수는 하나의 프로세스 또는 커널이 메모리의 한 페이지를 (직접 혹은 새로운 페이지 안의 폴트로 인해서) 할당하고자 하며, 커널이 모든 사용 가능한 자유 메모리를 사용하고 있을 때 일어납니다. 이것은 커널에게 하나의 페이지를 해제하는 동안 할당을 막도록 요구합니다. 결국 이것은 더티한 File-backed 페이지를 플러싱하기 위한 디스크 I/O나 lowmemorykiller가 프로세스 하나를 죽이기를 기다리는 것을 종종 요구합니다. 이것은 UI 스레드를 포함하는 어떤 스레드에 추가 I/O를 일으킬 수 있습니다.
직접 회수를 피하기 위해서 커널은 kswapd나 백그라운드 회수를 촉발시키는 워터마크를 가집니다. 이것은 페이지들을 해제하도록 시도해서 다음에 그를 할당하는 리얼 타임 스레드가 빨리 수행할 수 있도록 하는 하나의 스레드입니다.
백그라운드 회수를 촉발시키는 디폴트 임계값은 2GB 디바이스에서 2MB, 512MB 디바이스에서 636KB로, 상당히 낮습니다. 그리고 커널은 그저 수 MB의 메모리를 백그라운드 회수 시에 회수할 뿐입니다. 이것은 수 MB 이상을 빨리 할당하는 어떤 프로세스는 빨리 직접 회수를 치게 될 것이라는 것을 의미합니다.
새로운 커널에 튜닝 가능한 지원이 android-3.4 커널 브랜치에 패치 92189d47f66c67e5fd92eafaa287e153197a454f(“add extra free kbytes tunable”)로 추가됩니다. 이 패치를 디바이스의 커널로 체리픽하는 것은 ActivityManager가 커널에게 3개의 풀스크린 32 bpp 버퍼의 메모리를 자유롭게 유지하도록 할 것임을 이야기하는 것을 허용할 것입니다.
이들 임계값은 프레임워크 config.xml을 통해 설정될 수 있습니다.
<!– 커널 내에 (존재한다면) 튜닝 가능한 /proc/sys/vm/extra_free_kbytes를 셋팅하는 디바이스 설정. 높은 값은 커널이 free를 유지하는 메모리의 양을 증가시키고, 할당 시간을 줄이고, lowmemerykiller가 더 빨리 죽이도록 할 것입니다. 낮은 값은 프로세스들에 의해 더 많은 메모리를 사용하도록 하지만 디스크 I/O나 lowmemorykiller 상에서의 대기를 막는 더 많은 할당이 일어날 것입니다. 화면 크기에 기초한 ActivityManager에 의해 선택된 기본 값은 덮어씌움. 0은 커널의 기본 값을 넘는 추가 메모리를 유지하는 것을 막습니다. -1은 기본값을 유지합니다 –>
<integer name=”config_extraFreeKbytesAbsolute”>-1</integer>
<!– 커널 내에 (존재한다면) 튜닝 가능한 /proc/sys/vm/extra_free_kbytes를 조정하는 디바이스 설정. 0은 ActivityManager가 고르는 기본 값을 사용합니다. 양수 값은 커널이 해제를 유지하는 메모리의 양을 증가시키고, 할당 시간을 줄이고, lowmemorykiller 가 더 빨리 죽이도록 할 것입니다. 음수 값은 프로세스들에 의해 사용되는 메모리를 더 많이 허용하지만, 디스크 I/O나 lowmemorykiller 상의 대기를 막는 더 많은 할당이 일어날 것입니다. 화면 크기에 기초한 ActivityManager에 의해 선택된 기본 값은 직접 더해짐. –>
<integer name=”config_extraFreeKbytesAdjust”>0</integer>
LowMemoryKiller 튜닝
ActivityManager는 각 우선 순위 단계 버킷 안에서 프로세스를 실행하는데 필요한 file-backed 페이지(캐시된(cached) 페이지)의 워킹 셋의 그 예상치를 맞추기 위해서 LowMemoryKiller의 임계값을 설정합니다. 디바이스가 워킹 셋을 위한 높은 요구 사항을 갖는다면, 예를 들면, 벤더 UI가 더 많은 메모리를 요구하거나 더 많은 서비스가 추가되었다면, 임계값은 증가될 수 있습니다.
작아지고 있는 캐시 때문에 디스크 스레싱(thrashing)이 일어나기 전에 백그라운드 프로세스들이 죽여지고 있어서, 너무 많은 메모리가 file backed 페이지를 위해 예약되어 지고 있다면 임계값을 줄일 수 있습니다. 
<!– 커널 내의 lowmemorykiller 내의 튜닝 가능한 minfree를 셋팅하는 디바이스 설정. 높은 값은 lowmemorykiller가 더 일찍 켜지고, 파일 캐시 안에 더 많은 메모리를 유지하고, I/O 스레싱을 막도록 할 것이지만, 메모리 내에 더 적은 프로세스가 머물도록 할 것입니다. 낮은 값은 더 많은 프로세스가 메모리 상에 유지되지만, 너무 낮으면 스레싱을 일으킬 것입니다. 화면 크기와 가장 큰 lowmemorykiller 버킷을 위한 전체 메모리에 기초해서 ActivityManager에 의해 선택된 기본값을 덮어쓰고, 더 작은 버킷에 비례해서 크기가 조정됨. -1은 기본값을 유지 —>
<integer name=”config_lowMemoryKillerMinFreeKbytesAbsolute”>-1</integer>
<!– 커널 내의 lowmemorykiller 내의 튜닝 가능한 minfree를 조정하는 디바이스 설정. 높은 값은 lowmemorykiller가 더 일찍 켜지고, 파일 캐시 안에 더 많은 메모리를 유지하고, I/O 스레싱을 막도록 할 것이지만, 메모리 내에 더 적은 프로세스가 머물도록 할 것입니다. 낮은 값은 더 많은 프로세스가 메모리 상에 유지되지만, 너무 낮으면 스레싱을 일으킬 것입니다. 화면 크기와 가장 큰 lowmemorykiller 버킷을 위한 전체 메모리에 기초해서 ActivityManager에 의해 선택된 기본값에 직접 더해지고, 더 작은 버킷에 비례해서 크기가 조정됨. 0은 기본값을 유지 —>
<integer name=”config_lowMemoryKillerMinFreeKbytesAdjust”>0</integer>

Framework의 설정 참고 소스 코드: frameworks/base/services/java/com/android/server/am/ProcessList.java

[Linux:Kernel] 왜 “volatile” 타입 클래스가 쓰이지 않는 것이 좋을까

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).
Documentation/volatile-considered-harmful.txt
번역: 양정석<dasomoli@gmailREMOVETHIS.com>
왜 “volatile” 타입 클래스가 쓰이지 않는 것이 좋은가
—————————————————
C 프로그래머들은 종종 volatile을 그 변수가 현재 스레드의 실행 밖에서 바뀔 수
있다는 의미로 사용합니다; 그 결과, 그들은 가끔 커널 코드 안에서 공유 자료
구조들을 사용할 때 이를 사용하고자 합니다. 다른 말로 하면, 그들은 간단한
atomic 변수의 일종처럼, 그게 아닌데도, volatile 형식을 다루는 것으로 알고
있습니다. volatile 커널 코드의 용도는 거의 절대 맞지 않습니다; 이 문서는 그
이유를 설명합니다.
volatile에 대한 이해를 위한 핵심은 그 목적이 거의 아무도 절대 진정으로 원하지
않는 최적화를 막기 위해서라는 것입니다. 커널 안에서, 누군가는 공유되는
자료 구조를 매우 다른 태스크의 원치 않는 동시 접근으로부터 보호해야 합니다.
원치 않는 동시성에 대한 보호 처리는 또한 거의 모든 최적화에 관련된 문제를 더
효율적인 방법으로 피할 것입니다.
volatile처럼, 자료로 안전하게 동시 접근을 하는 커널 기본 요소(스핀락(spinlock),
뮤텍스(mutex), 메모리 장벽(memory barrier), 기타 등등)는 원치 않는 최적화를
막도록 설계되었습니다. 그들이 적절히 사용된다면, 그들은 volatile을 사용할
필요가 없을 것입니다. volatile이 여전히 필요하다면, 거기에는 거의 확실히 코드
어딘가에 버그가 있습니다. 적절히 작성된 커널 코드 안에서 volatile은 오직
느리게만 만들 것입니다.
일반적인 커널 코드 블록을 생각해 봅시다:
    spin_lock(&the_lock);
    do_something_on(&shared_data);
    do_something_else_with(&shared_data);
    spin_unlock(&the_lock);
모든 코드가 락킹(locking) 규칙을 따른다면, shared_data의 값은 the_lock이 잡힌
동안, 예기치 않게 바뀔 수 없습니다. 그 자료를 가지고 놀고 싶어 할 어떤 다른
코드는 락 상에서 대기할 것입니다. 스핀락 기본 요소는 자료 접근이 그들을
가로지르는 최적화가 되지 않을 것임을 의미하는 메모리 장벽처럼 – 그들은
명시적으로 그렇게 하도록 작성되었습니다 – 동작합니다. 그래서 컴파일러는 그것이
shared_data 안에 있을 것을 안다고 생각할 수도 있지만. spin_lock() 호출이 메모리
장벽처럼 동작한 이후에는, 컴파일러가 알고 있는 어떠한 것도 잊어버리도록 강제할
것입니다. 거기에는 그 자료로의 접근에 대한 최적화 문제는 없을 것입니다.
shared_data가 volatile로 선언되었어도, 락킹은 여전히 필요할 것입니다.
그러나 컴파일러 역시, 우리가 다른 누구도 그것으로 무언가 할 수 없음을 알 때,
크리티컬 섹션 _안에서는_ shared_data로의 접근에 대한 최적화가 막혔으면 할
것입니다. 락이 잡힌 동안, shared_data는 volatile이 아닙니다. 공유된 자료로
뭔가 할 때, 적절한 락킹은 – 잠재적으로 해로운 – volatile을 불필요하게 만들 것
입니다.
volatile 저장 클래스는 근본적으로 메모리-매핑된(memory-mapped) I/O 레지스터들을
위해 의미가 있습니다. 커널 안에서 레지스터 접근 역시 락으로 보호돼야 합니다만,
누군가는 또한 컴파일러가 크리티컬 섹션 안에서 레지스터 접근을 “최적화하는 것”을
원하지 않습니다. 그러나 커널 안에서, I/O 메모리 접근은 언제나
접근자(accessor) 함수를 통해 이루어집니다; I/O 메모리에 포인터를 통해 직접
접근하는 것은 얼굴이 찡그려지고, 모든 아키텍처에서 작동하지 않습니다.
이들 접근자는 원치 않는 최적화를 막도록 작성되었습니다. 그래서, 역시,
volatile은 불필요합니다.
누군가가 volatile을 사용하고자 하는 또 다른 상황은 프로세서가 한 변수의 값을
위해 바쁜-기다림(busy-waiting)을 할 때입니다. 바쁜 기다림을 수행하는 옳은
방법은:
    while (my_variable != what_i_want)
        cpu_relax();
cpu_relax() 호출은 CPU 전력 소비를 낮출 수 있고, 하이퍼 스레드 된 다른
프로세서에 양보할 수 있습니다; 또한 컴파일러 장벽처럼 서비스하는 일이
일어납니다. 그래서, 역시, volatile은 불필요합니다. 물론, 바쁜 기다림은
일반적으로 시작하는 반사회적 행동입니다.
volatile이 커널 안에서 이해되는 적은 수의 드문 상황들이 여전히 있습니다:
  – 직접 I/O 메모리 접근이 동작하는 아키텍처에서는 위에서 설명된 접근자
    함수들이 volatile을 사용할 수 있습니다. 기본적으로, 각 접근자 호출은
    그 자체로 작은 크리티컬 섹션이 되고, 접근이 프로그래머가 의도한 대로
    일어남을 보장합니다.
  – 메모리를 변경하는, 그렇지만 다른 보이는 부수 효과(side effect)나, GCC에 의해
    제거되는 위험 없는 인라인 어셈블리 코드. volatile 키워드를 asm 문장에
    추가하는 것은 이 제거를 막을 것입니다.
  – jiffies 변수는 그것이 참조되는 순간마다 다른 값을 가지지만, 어떤 특별한
    락킹도 없이 읽힐 수 있어서 특별합니다. 그래서 jiffies는 volatile일 수
    있지만, 이 타입의 다른 변수들의 추가는 강하게 얼굴이 찌푸려집니다.
    jiffies는 이런 점에서 (리누스의 말로) “멍청한 유산” 이슈로 생각됩니다; 이를
    고치는 것은 그 가치보다 더 많은 문제를 일으킬 수 있습니다.
  – 가끔 합법적으로 volatile이 될 수 있는 I/O 장치에 의해 수정될 수 있는
    일관적인(coherent) 메모리 안의 자료 구조로의 포인터. 네트워크 어댑터가 어떤
    기술자(descriptor)가 처리되었는지를 나타내기 위해 포인터를 수정하는 데서,
    그 어댑터에 의해 사용되는 링 버퍼가 이런 종류 상황의 한 예제입니다.
코드 대부분에서, volatile의 적용을 위한 위의 타당한 이유가 없습니다. 그 결과,
volatile의 사용은 버그처럼 보이고, 코드에 추가적인 정밀 조사를 가져오도록 할
가능성이 큽니다. volatile을 사용하고자 하는 개발자들은 발걸음을 돌리고 그들이
정말로 하고자 하는 바에 대해서 생각해 봐야 할 것입니다.
volatile 변수들의 제거 패치는 – 그들이 동시성 이슈들을 적절히 생각했음을
보여주는 타당한 이유로 다가오는 만큼 – 일반적으로 환영받습니다.
참고
—-
[1] http://lwn.net/Articles/233481/
[2] http://lwn.net/Articles/233482/
언급해야 할 이름
—————-
원래의 자극과 연구는 Randy Dunlap에 의해
작성은 Jonathan Corbet에 의해
의견을 통한 개선은 Satyam Sharma, Johannes Stezenbach, Jesper
Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
Richter로부터.
한국어 번역은 양정석이.

[Linux:Kernel] 동적 디버그 사용법(dynamic debug howto.txt)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/dynamic-debug-howto.txt

번역: 양정석<dasomoli@gmailREMOVETHIS.com>

소개

====

이 문서는 어떻게 동적 디버그 (Dynamic Debug:dyndbg) 기능을 사용하는지 설명합니다.

동적 디버그는 여러분이 추가적인 커널 정보를 얻을 수 있도록 동적으로 커널 코드를 켜고/끌

수 있도록 설계되었습니다. 현재는 CONFIG_DYNAMIC_DEBUG가 설정되어 있다면, 모든

pr_debug()/dev_dbg() 그리고 print_hex_dump_debug()/

print_hex_dump_bytes() 호출은 호출하는 지점마다(per-callsite) 동적으로 켜질

수 있습니다.

CONFIG_DYNAMIC_DEBUG가 설정되어 있지 않으면, print_hex_dump_debug()는

그저 print_hex_dump(KERN_DEBUG)의 축약입니다.

print_hex_dump_debug()/print_hex_dump_bytes()에서 만약 그것이 변하지 않는

문자열이라면 형식 문자열(format string)은 그 ‘prrefix_str’ 인자입니다;

또는 ‘prefix_str’ 이 빌드 시 동적인 경우라면 “hexdump”.

동적 디버그는 더 유용한 기능들도 가집니다:

 * 0이나 1의 조합으로 매칭해서 디버깅 문장을 끄고 켤 수 있도록 하는 간단한 쿼리 언어:

   – 소스 파일 이름

   – 함수 이름

   – (행 번호의 범위를 포함하는) 행 번호

   – 모듈 이름

   – 형식 문자열

 * debugfs 제어 파일 제공: 여러분을 안내하는데 도움이 되도록, 알려진 디버그 문장들의

   완전한 목록을 보이도록 읽혀질 수 있는 <debugfs>/dynamic_debug/control.

동적 디버그 동작 제어하기

=========================

pr_debug()/dev_dbg()의 동작은 이 기능의 용도에 따라 ‘debugfs’ 파일 시스템 내의

제어 파일에 쓰는 것을 통해 제어됩니다. 이어서, 우리는 제어 파일을 알아봅니다:

<debugfs>/dynamic_debug/contorl. 예를 들어, 여러분이 소스 파일 ‘svcsock.c’의

1603번째 행에서 출력을 켜기를 원한다면, 간단히 이렇게 하세요:

nullarbor:~ # echo ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

여러분이 문법을 틀린다면, 쓰기가 실패할 것입니다:

nullarbor:~ # echo ‘file svcsock.c wtf 1 +p’ >
<debugfs>/dynamic_debug/control

-bash: echo: write error: Invalid argument

동적 디버그 동작 보기

=====================

여러분은 다음을 통해 현재 설정된 모든 디버그 문장의 동작을 볼 수 있습니다:

nullarbor:~ # cat <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ “SVCRDMA Module Removed, deregister RPC RDMA transport\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ “\011max_inline       : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ “\011sq_depth         : %d\012”

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ “\011max_requests     : %d\012”


여러분은 또한 이 데이터에 표준 유닉스 텍스트 조작 필터를 적용할 수 있습니다. 예를 들면,

nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control  | wc -l

62

nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l

42

세번째 열은 현재 각 디버그 문장을 호출하는 곳마다의 켜짐 플래그(이 플래그의 정의는

아래를 보세요)를 보여줍니다. 아무 플래그도 설정되지 않은, 기본 값은 “=_” 입니다.

그래서 여러분은 모든 디버그 문장 호출처를 기본값이 아닌 플래그로 볼 수 있습니다:

nullarbor:~ # awk ‘$3 != “=_”‘ <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p “svc_process: st_sendto returned %d\012”

명령 언어 레퍼런스

==================

어휘적인 수준에서, 하나의 명령은 스페이스나 탭으로 나뉘어진 단어 순서로 구성됩니다.

그래서 이들은 모두 동등합니다:

nullarbor:~ # echo -c ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -c ‘  file   svcsock.c     line  1603 +p  ‘ >
<debugfs>/dynamic_debug/control

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

명령 제출은 write() 시스템 호출로 경계지어집니다. 여러 명령은 ‘;’ 나 ‘\n’ 으로

나뉘어져서 함께 쓰여질 수 있습니다.

  ~# echo “func pnpacpi_get_resources +p; func pnp_assign_mem +p” \

     > <debugfs>/dynamic_debug/control

여러분의 쿼리 집합이 크다면, 역시 이를 일괄적으로 수행할 수 있습니다:

  ~# cat query-batch-file > <debugfs>/dynamic_debug/control

다른 방법은 와일드카드를 사용하는 것입니다. 매치 규칙은 ‘*’ (0개나 그 이상의 문자들과

매치)과 ‘?’ (정확히 하나의 문자와 매치)를 지원합니다. 예를 들면, 여러분은 모든 usb

드라이버들을 매치시킬 수 있습니다:

  ~# echo “file drivers/usb/* +p” > <debugfs>/dynamic_debug/control

문법적인 수준에서, 매치 명세(match-spec)들, 그 뒤에 플래그 변경 명세(flags-spec)

의 순서로 구성됩니다.

command ::= match-spec* flags-spec

매치 명세들은 플래그 변경 명세를 어디에 적용해야 하는지를 위해 알려진 pr_debug()

호출처의 부분 집합을 고르는데 사용됩니다. 각 짝들 사이에 암묵적인 AND로 하나의 쿼리처럼

그들을 생각하세요. 매치 명세의 빈 목록은 모든 디버그 문장 호출처를 선택함을 알아두세요.

매치 명세는 비교되는 호출처의 속성을 제어하는 하나의 키워드, 그리고 비교될 하나의 값으로

구성됩니다. 가능한 키워드들은:

match-spec ::= ‘func’ string |
      ‘file’ string |
      ‘module’ string |
      ‘format’ string |
      ‘line’ line-range

line-range ::= lineno |
      ‘-‘lineno |
      lineno’-‘ |
      lineno’-‘lineno

// 알림: line-range 스페이스를 포함할 수 없습니다. 예를 들면,

// “1-30″은 유효한 범위이지만, “1 – 30″은 아닙니다.

lineno ::= unsigned-int

각 키워드의 뜻은:

func

    주어진 문자열은 각 호출처의 함수 이름과 비교됩니다 예를 들면:

    func svc_tcp_accept

file

    주어진 문자열은 전체 경로 이름이나 소스 루트의(src-root) 상대 경로 이름, 또는 각

    호출처의 소스 파일의 경로를 제외한 이름(basename)과 비교됩니다. 예를 들면:

    file svcsock.c

    file kernel/freezer.c

    file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c

module

    주어진 문자열은 각 호출처의 모듈 이름과 비교됩니다. 모듈 이름은 “lsmod” 에서 보여지는

    문자열입니다. 즉, 디렉토리나 .ko 접미사가 없고, ‘-‘는 ‘_’로 변경됩니다. 예를 들면:

    module sunrpc

    module nfsd

format

    주어진 문자열은 동적 디버그 형식 문자열 내에서 검색됩니다. 그 문자열은 전체 형식과

    매치될 필요는 없고 오직 일부만 매치되면 된다는 것을 알아두세요. 공백 문자들과 다른

    특수 문자들은 C의 8진수 문자 이스케이프 \ooo 표현을 사용해서 쓰여질 수 있습니다.

    예를 들면, 스페이스 문자는 \040 입니다. 다른 방식으로, 문자열을 쌍따옴표 문자(“) 나

    따옴표(‘)로 둘러쌀 수 있습니다.

    예제:

    format svcrdma:
   // NFS/RDMA 서버 pr_debug 들에서 많음

    format readahead
   // readahead 캐시 안의 pr_debug 들

    format nfsd:\040SETATTR // 공백 문자로 형식을 매치하는 한가지 방법

    format “nfsd: SETATTR”  // 공백 문자로 형식을 매치하는 더 깔끔한 방법

    format ‘nfsd: SETATTR’  // 공백 문자로 형식을 매치하는 또 다른 방법

line

    주어진 행 번호 또는 행 번호의 범위는 각 pr_debug() 호출처의 행 번호와 비교됩니다.

    하나의 행 번호는 호출처 행 번호와 정확히 매치됩니다. 행 번호의 범위는 처음과 마지막의

    행 번호 안의 호출처와 매치됩니다. 첫번째 수가 없는 것은 파일의 첫번째 줄을 의미하고,

    행 번호가 없는 것은 파일의 마지막 줄을 의미합니다. 예를 들면: 

    line 1603
   // 정확히 1603번 줄

    line 1600-1605  // 1600번에서 1605번 줄까지의 여섯 줄

    line -1605
   // 1번 줄에서 1605번 줄까지의 1605 줄

    line 1600-
   // 1600번 줄에서 파일의 끝까지의 모든 줄

플래그 명세는 하나 또는 그 이상의 플래그 성질이 따르는 하나의 변경 동작으로 구성됩니다.

변경 동작은 하나의 성질입니다:

  –    주어진 플래그 제거

  +    주어진 플래그 추가

  =    주어진 플래그로 플래그를 설정

플래그들은 다음과 같습니다:

  p    pr_debug() 호출처 켜기

  f    출력된 메시지 안에 함수 이름을 포함

  l    출력된 메시지 안에 행 번호를 포함

  m    출력된 메시지 안에 모듈 이름을 포함

  t    인터럽트 컨텍스트에서 생성되지 않은 메시지 안에 스레드 ID 포함.

  _    플래그가 설정되지 않음. (또는 입력 상의 다른 것들로 설정)

print_hex_dump_debug()와 print_hex_dump_bytes()에서는, 오직 ‘p’ 플래그가

다른 플래그들이 무시되는 것을 의미합니다.

보여줄 때, 플래그들은 ‘=’이 앞에 옵니다(연상 기호: 무슨 플래그가 현재 동일한지).

Note the regexp ^[-+=][flmpt_]+$ matches a flags specification.

To clear all flags at once, use “=_” or “-flmpt”.

정규표현 ^[-+=][flmpt_]+$ 는 플래그 명세와 매치함을 알아두세요.

모든 플래그를 없애기 위해서, “=_” 나 “-flmpt”를 사용하세요.

부트 프로세스 동안의 디버그 메시지

==================================

부트 프로세스 동안의 코어 코드와 빌트인 모듈 디버그 메시지를 활성화 하기 위해서, 유저 공간과

debugfs 가 존재하기 전에도, dyndbg=”QUERY”, module.dyndbg=”QUERY”, 또는

ddebug_query=”QUERY”(ddebug_query는 dyndbg에 의해 구식이 되었고, 더 이상 사용하지

않습니다)를 사용할 수 있습니다. QUERY는 위에 설명된 문법을 따르지만, 1023 문자를 넘을 수

없습니다. 여러분의 부트로더는 제한으로 더 적은 수를 쓰고 있을 수 있습니다.

이들 dyndbg 파라미터들은 ddebug 테이블이 처리된 후에, arch_initcall 의 일부로

바로 처리됩니다. 그래서 여러분은 이 부트 파라미터를 통해 이 arch_initcall 이후에

모든 코드 안의 디버그 메시지를 켤 수 있습니다.

예를 들면, x86 시스템 상에서 ACPI 활성화는 subsys_initcall 이고,

   dyndbg=”file ec.c +p”

는 여러분의 머신(일반적으로 랩탑)이 임베디드 컨트롤러를 가진다면, ACPI 셋업동안 초기 임베디드

컨트롤러 트랜잭션을 보여줄 것입니다.

PCI (또는 다른 장치들의) 초기화는 또한 디버깅 목적의 이 부트 파라미터 사용의 유력한

후보들입니다.

foo 모듈이 빌트-인이 아니라면, foo.dyndbg 는 여전히 부트 타임에 아무 효과 없이 처리될

것입니다만, 모듈이 이후에 로딩될 때 처리될 것입니다. dyndbg_query= 과 순수한 dyndbg= 은

부트 시에만 처리됩니다.

모듈 초기화 시점의 디버그 메시지

================================

“modprobe foo”가 호출될 때, modprobe는 foo.params를 위해 /proc/cmdline을 스캔하고,

“foo.”을 벗겨서 제거하고, 이를 modprobe args 나 /etc/modprob.d/*.conf 파일 안에

주어진 파라미터들과 함께 다음 순서로 커널에게 넘긴다:

1. # /etc/modprobe.d/*.conf를 통해 주어진 파라미터들

   options foo dyndbg=+pt

   options foo dyndbg # +p로 기본

2. # boot args에서 주어진 foo.dyndbg, “foo.” 는 벗겨져서 제거되어 전달됨

   foo.dyndbg=” func bar +p; func buz +mp”

3. # modprobe로의 args

   modprobe foo dyndbg==pmf # 이전 설정을 덮어 씀

이들 dyndbg 쿼리들은 가장 마지막에 말한 것이 마지막에 적용되도록, 순서대로 적용됩니다.

이것은 boot args가 /etc/modprobe.d(정확하게는 1이 시스템 전체, 2는 커널이나 부트에

의존적임)로부터 이들을 수정하거나 덮어 쓰도록, 그리고 modeprbe args 가 둘 다를 덮어쓰도록

합니다.

foo.dyndbg=”QUERY” 형식 안에서, 쿼리는 반드시 “foo 모듈”을 제외해야 합니다.

“foo”는 param-name 으로부터 추출되고, “QUERY” 내의 각 쿼리에 적용되고, 오직

각 타입의 1 match-spec만 적용됩니다.

dyndbg 옵션은 “가짜” 모듈 파라미터입니다. 이는 다음을 의미합니다:

– 모듈들은 그를 명시적으로 정의할 필요가 없습니다.

– 모든 모듈은 그들이 pr_debug를 사용하든 말든, 아무 말 없이 이를 얻을 수 있습니다.

– 그것은 /sys/module/$module/parameters 안에 나타나지 않습니다. 이를 보기 위해서,

  제어 파일을 grep 하거나, /proc/cmdline 을 검사하세요.
CONFIG_DYNAMIC_DEBUG 커널에서는 디버그 메시지가 더이상 필요하지 않다면, 부트-타임에
주어진 (또는 컴파일 동안 -DDEBUG 플래그에 의해 켜진) 어떠한 셋팅도 이후에 sysfs
인터페이스를 통해 끌 수 있습니다.

   echo “module module_name -p” > <debugfs>/dynamic_debug/control

예제

====

// svcsock.c 파일의 1603번째 줄의 메시지를 켜기

nullarbor:~ # echo -n ‘file svcsock.c line 1603 +p’ >
<debugfs>/dynamic_debug/control

// svcsock.c 파일 안의 모든 메시지 켜기

nullarbor:~ # echo -n ‘file svcsock.c +p’ >
<debugfs>/dynamic_debug/control

// NFS 서버 모듈의 모든 메시지 켜기

nullarbor:~ # echo -n ‘module nfsd +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 켜기

nullarbor:~ # echo -n ‘func svc_process +p’ >
<debugfs>/dynamic_debug/control

// svc_process() 함수 안의 모든 12 메시지를 끄기

nullarbor:~ # echo -n ‘func svc_process -p’ >
<debugfs>/dynamic_debug/control

// NFS가 호출하는 READ, READLINK, READDIR 그리고, READDIR+를 위한 메시지 켜기

nullarbor:~ # echo -n ‘format “nfsd: READ” +p’ >
<debugfs>/dynamic_debug/control

// “usb” 문자열을 포함하는 경로의 메시지 켜기

nullarbor:~ # echo -n ‘*usb* +p’ > <debugfs>/dynamic_debug/control

// 모든 메시지 켜기

nullarbor:~ # echo -n ‘+p’ > <debugfs>/dynamic_debug/control

// 모든 켜진 메시지에 모듈과 함수 추가

nullarbor:~ # echo -n ‘+mf’ > <debugfs>/dynamic_debug/control

// boot-args 예제, 가독성을 위해 줄바꿈과 주석을 넣음

Kernel command line: …

  // dyndbg=값 처리 안에서 어떻게 되어가고 있는지 보기

  dynamic_debug.verbose=1

  // 2 빌트인 안의 pr_debug 켜기, #cmt 는 제거됨

  dyndbg=”module params +p #cmt ; module sys +p”

  // 나중에 로딩되는 모듈 안의 2 함수 안의 pr_debug를 켜기

  pc87360.dyndbg=”func pc87360_init_device +p; func pc87360_find +p”

[Linux:Kernel] 커널 메모리 누수 검출기

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/kmemleak.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

커널 메모리 누수 검출기
=======================

소개
—-

Kmemleak은 주인없는 객체들을 해제하지는 않고 그저 /sys/kernel/debug/kmemleak을
통해 보고하는 차이가 있는 가비지 컬렉터 추적
(http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Tracing_garbage_collectors)
과 비슷한 방법으로, 가능한 커널 메모리 누수를 검출하는 방법을 제공합니다. 유저-공간의
애플리케이션에서 메모리 누수를 검출하는 데 Valgrind 도구(memcheck –leak-check)가
유사한 방법을 사용합니다.

지원되는 아키텍처를 위해 lib/Kconfig.debug 안의 DEBUG_KMEMLEAK 의존성을 체크하세요.

사용법
——

“Kernel hacking” 안의 CONFIG_DEBUG_KMEMLEAK이 켜져야 합니다. 한 커널 스레드가
메모리를 (기본값으로) 매 10분마다 스캔하고, 찾은 새로운 참조되지 않는 객체들의
수를 출력합니다. 모든 가능한 메모리 누수의 자세할 사항을 보기 위해서는:

  # mount -t debugfs nodev /sys/kernel/debug/
  # cat /sys/kernel/debug/kmemleak

중간에 메모리 스캔을 작동시키려면:

  # echo scan > /sys/kernel/debug/kmemleak

모든 현재의 가능한 메모리 누수의 목록을 지우려면:

  # echo clear > /sys/kernel/debug/kmemleak

그려면 새로운 누수는 /sys/kernel/debug/kmemleak을 다시 읽음으로써 나올 것입니다.

주인없는 객체들은 그들이 할당되었던 순서로 나열되고, 목록의 맨 앞의 한 객체는
주인없는 것으로 보고되는 다른 이어지는 객체들의 원인이 될 것입니다.

메모리 스캐닝 파라미터들은 런타임에 /sys/kernel/debug/kmemleak 파일에 씀으로써
바뀔 수 있습니다. 다음 파라미터들이 지원됩니다:

  off           – kmemleak 끄기 (되돌릴 수 없음)
  stack=on      – 태스크 스택 스캐닝 켜기 (기본값)
  stack=off     – 태스크 스택 스캐닝 끄기
  scan=on       – 자동 메모리 스캐닝 스레드 시작하기 (기본값)
  scan=off      – 자동 메모리 스캐닝 스레드 멈추기
  scan=<secs>   – 자동 메모리 스캐닝 주기를 초로 설정
                  (기본 600, 0은 자동 스캐닝 멈춤)
  scan          – 한 번의 메모리 스캔 작동
  clear         – 현재 메모리 누수 혐의자들의 목록 지우기, 모든 현재 보고된
                  참조되지 않는 객체를 회색으로 표시함으로써 끝
  dump=<addr>   – <주소>에서 찾아진 객체에 대한 정보를 덤프

Kmemleak은 또한 부팅 시간에 “kmemleak=off”를 커널 커맨드 라인에 전달함으로써
꺼질 수도 있습니다.

kmemleak이 초기화되기 전에 메모리는 할당되거나 해제될 것이고, 이들 동작은 초기
로그 버퍼 안에 저장될 것입니다.이 버퍼의 크기는
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE 옵션을 통해 설정됩니다.

기본 알고리즘
————-

kmalloc, vmalloc, kmem_cache_alloc과 그 친구들을 통한 메모리 할당은 추적되고,
그 포인터들은, 크기나 스택 추적같은 추가 정보와 함께 prio 검색 트리 안에
저장됩니다. 그에 맞는 해제 함수 호출들은 기록되고 그 포인터들은 kmemleak 자료
구조로부터 제거됩니다.

메모리의 할당된 블록이 (저장된 레지스터들을 포함하는) 메모리 스캐닝을 통해
그 시작 주소나 블록 안의 어떤 위치로의 어떤 포인터도 찾을 수 없다면, 주인없는
것으로 여겨집니다. 이것은 커널이 할당된 블록의 주소를 해제하는 함수로 넘길 수
있는 방법이 없을 것이고, 그래서 그 블록이 메모리 누수라고 여겨진다는 것을
의미합니다.


스캐닝 알고리즘 단계:

  1. 모든 객체를 하얗게 표시 (남은 하얀 객체들은 나중에 주인없는 것으로 여겨질
     것 입니다.)
  2. 데이터 섹션과 스택들의 메모리 시작을 스캔, prio 검색 트리 안에 저장된 주소들에
     대조되는 값을 검사. 하얀 객체로의 포인터가 있다면, 그 객체는 회색 목록에
     추가합니다.
  3. 회색 집합이 끝날 때까지 매칭되는 주소들을 위해 회색 객체들을 스캔(어떤
     하얀 객체들은 회색이 되고, 회색 목록의 끝에 추가됩니다)
  4. 남아있는 하얀 객체들은 주인없는 것으로 여겨지고, /sys/kernel/debug/kmemleak
     을 통해 보고됩니다.

어떤 할당된 메모리 블록들은 커널의 내부 자료 구조 안에 저장된 포인터들을 가지고,
그들은 주인없는 것으로 검출될 수 없습니다. 이를 피하기 위해서, kmemleak은
또한, 찾아질 필요가 있는 블록 주소 범위 내의 주소를 가리키는 값의 수를 저장할
수 있어서 그 블록은 누수로 여겨지지 않습니다. 한 예로 __vmalloc()이 있습니다.

kmemleak으로 특정 섹션 테스트하기
———————————

초기 부팅 상에서 여러분의 /sys/kernel/debug/kmemleak 출력 페이지는 좀
많을 것입니다. 이것은 또한 여러분이 개발을 할 때 매우 버그가 많은 코드를
가진다면 있을 수 있습니다. 이런 상황에서 일하기 위해서
/sys/kernel/debug/kmemleak 출력으로부터 모든 보고된 참조되지 않는 객체를
지우기 위해서 여러분은 ‘clear’ 명령을 사용할 수 있습니다. ‘clear’ 후의
‘scan’을 통해, 여러분은 새로운 참조되지 않는 객체들을 찾을 수 있습니다;
이것은 코드의 특정 섹션을 테스팅하는 데 도움이 될 것입니다.

깨끗한 kmemleak으로 하고 싶을 때 크리티컬 섹션을 테스트하기 위해서는
이렇게 하세요:

  # echo clear > /sys/kernel/debug/kmemleak
  … 여러분의 커널이나 모듈을 테스트 …
  # echo scan > /sys/kernel/debug/kmemleak

그 후, 여느 때처럼 여러분의 보고서를 얻기 위해서:

  # cat /sys/kernel/debug/kmemleak

Kmemleak API
————

함수들의 프로토 타입은 /include/linux/kmemleak.h 헤더를 보세요.

kmemleak_init            – kmemleak 초기화
kmemleak_alloc           – 하나의 메모리 블록 할당 알림
kmemleak_alloc_percpu    – 하나의 percpu 메모리 블록 할당 알림
kmemleak_free            – 하나의 메모리 블록 해제 알림
kmemleak_free_part       – 하나의 부분 메모리 블록 해제 알림
kmemleak_free_percpu     – 하나의 percpu 메모리 블록 해제 알림
kmemleak_not_leak        – 누수가 아닌 것으로 객체 표시
kmemleak_ignore          – 스캔하지 않거나, 누수로 객체를 보고하지 않음
kmemleak_scan_area       – 메모리 블록내의 스캔 지역 추가
kmemleak_no_scan         – 메모리 블록 스캔하지 않음
kmemleak_erase           – 포인터 변수 안의 이전 값을 지움
kmemleak_alloc_recursive – kmemleak_alloc과 같지만 재귀성 검사
kmemleak_free_recursive  – kmemleak_free와 같지만 재귀성 검사

거짓 검출/미검출의 처리
———————–

거짓 미검출은 진짜 메모리 누수(주인없는 개체)가 메모리 스캐닝 중에 찾은 값들이
객체들을 가리키고 있어서 kmemleak에 의해 보고되지 않는 것입니다.
거짓 미검출의 수를 줄이기 위해서, kmemleak은 kmemleak_ignore,
kmemleak_scan_area, kmemleak_no_scan, 그리고 kmemleak_erase 함수들
(위를 보세요)을 제공합니다. 태스크 스택은 또한 거짓 미검출의 양을 늘려서,
그들의 스캐닝은 기본값으로 켜지지 않습니다.

거짓 검출은 객체들이 메모리 누수(주인없음)이 된 것처럼 잘못 보고되는 것입니다.
누수가 아닌 것으로 알려진 객체들을 위해서, kmemleak은 kmemleak_not_leak
함수를 제공합니다. kmemleak_ignore 또한 그 메모리 블록이 다른 포인터들을
포함하는 것으로 알려지지 않았다면 사용될 수 있고, 더 이상 스캔되지 않을
것 입니다.

보고된 누수들 중 어떤 것들은 CPU 레지스터나 스택 안에 임시적으로 저장되는
포인터들 때문에, 특히 SMP 시스템 상에서, 그저 일시적입니다. Kmemleak은
메모리 누수로 보고되는 객체의 최소 나이를 표시하는 (기본은 1000인)
MSECS_MIN_AGE를 정의합니다.

제한과 결점
———–

주요 결점은 메모리 할당과 해제의 성능을 떨어뜨린 다는 것 입니다. 다른 불이익을
피하기 위해서, 메모리 스캐닝은 /sys/kernel/debug/kmemleak 파일을 읽을 때만
수행됩니다. 어쨌든, 이 도구는 성능이 가장 중요한 요구 사항이 아닌 곳에서의
디버깅을 목적으로 합니다.

알고리즘을 간단히 유지하기 위해서, kmemleak은 한 블록의 주소 범위 안의
어떤 주소를 가리키는 값들을 스캔합니다. 이것은 거짓 미검출의 수를 늘릴 것입니다.
그러나, 그것은 진짜 메모리 누수가 결국 보여지게 되도록 할 것입니다.

거짓 미검출의 다른 출처는 포인터가 아닌 값들안에 저장된 데이터입니다. 이후
버전에서는 kmemleak이 할당된 구조체 안의 포인터 멤버만 스캔할 수 있을 것입니다.
이 기능은 위에서 설명한 많은 거짓 미검출을 해결할 것 입니다.

이 도구는 거짓 검출을 보고할 수 있습니다. 할당된 블록이 해제를 필요로 하지 않는
곳(init_call 함수 안의 어떠한 경우), 그 포인터가 보통의 container_of
매크로가 아닌 다른 방법으로 계산되는 곳, 또는 그 포인터가 kmemleak이 스캔하지
않는 위치 안에 저장된 포인터인 곳 같은 경우들이 있습니다.

페이지 할당과 ioremap은 추적하지 않습니다.

[Linux:Kernel] PM Quality Of Service 인터페이스

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).
Documentation/power/pm_qos_interface.txt
번역: 양정석(dasomoli@gmailREMOVETHIS.com)
PM Quality Of Service 인터페이스.
이 인터페이스는 커널과 유저 모드에 그 파라미터 중 하나로 드라이버, 서브 시스템,
그리고 유저 공간 애플리케이션들에 의한 성능 기대 사항을 등록하기 위한
인터페이스를 제공합니다.
두가지 다른 PM QoS 프레임워크가 이용가능합니다:
1. cpu_dma_latency, network_latency, network_throughput을 위한 PM QoS 클래스들.
2. per-device PM QoS 프레임워크는 per-device 지연 제약 사항과 PM QoS 플래그를
관리하기 위한 API 를 제공합니다.
각 파라미터는 단위를 정의했습니다:
 * 지연(latency): usec
 * 만료(timeout): usec
 * 처리용량: kbs (킬로 비트 / 초)
1. PM QoS framework
이 인프라 구조는 여러개의 misc 디바이스 노드들을 구현된 파라미터 당 하나로
노출합니다. 파라미터들 구현 집합은 pm_qos_power_init() 과 pm_qos_params.h 에
의해 정의됩니다. 드라이버로부터 런타임에 설정 가능하거나 변경 가능한 사용 가능
파라미터들을 갖는 것이 오용되기 너무 쉬운 것으로 보여지기 때문에 이렇게
수행됩니다.
각 파라미터를 위해 성능 요구에 대한 리스트가 취합된(aggregated) 목표 값으로
관리됩니다. 취합된 목표 값은 그 요구 목록이나 그 리스트의 개체들로의 변경으로
갱신됩니다. 일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체들 안에
잡힌 요청 값의 최고 또는 최저 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스의 사용은 간단합니다:
void pm_qos_add_request(handle, param_class, target_value):
는 개체 하나를 그 리스트 안에 목표 값으로 식별된 PM QoS 클래스를 위해 삽입할
것입니다. 이 리스트로의 변경 위에서 새로운 목표는 재계산되고, 어떤 등록된
통지자(notifier)가 그 목표 값이 지금과 다를 때만 호출됩니다. pm_qos의
클라이언트는 다른 pm_qos API 함수들 안에서 추후에 사용될 때를 위해 반환된
핸들을 저장할 필요가 있습니다.
void pm_qos_update_request(handle, new_target_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 취합된 목표, 통지(notifictation) 트리 호출을 재계산합니다.
void pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의 결과로 바뀌면, 통지 트리를 호출할 것입니다.
int pm_qos_request(param_class):
는 주어진 PM QoS 클래스를 위한 취합된 값을 반환합니다.
int pm_qos_request_active(handle):
는 그 요청이 여전히 살아있는지를 반환합니다. 즉, PM QoS 클래스 제약 사항 리스트
로부터 제거되지 않았다는 것입니다.
int pm_qos_add_notifier(param_class, notifier):
는 통지 콜백 함수를 PM QoS 클래스로 추가합니다. 그 콜백은 PM QoS 클래스를 위한
취합된 값이 바뀌었을 때 호출됩니다.
int pm_qos_remove_notifier(int param_class, notifier):
는 PM QoS 클래스를 위한 통지 콜백 함수를 제거합니다.
유저 모드에서는:
프로세스들만 pm_qos 요청을 등록할 수 있습니다. 프로세스의 자동적인 청소 작업을
제공하기 위해서, 인터페이스는 프로세스에게 다음과 같은 방법으로 그 파라미터
요청을 등록하도록 요구합니다:
지정된 파라미터의 기본 pm_qos 목표를 등록하기 위해서, 프로세스는
/dev/[cpu_dma_latency, network_latency, network_throughput] 중 하나를
열어야만 합니다.
디바이스 노드가 연 것을 유지하는 동안 그 프로세스는 파라미터 상의 등록된
요청을 가집니다.
요청된 목표 값을 변경하기 위해서, 그 프로세스는 s32 값을 열린 디바이스 노드에
쓸 필요가 있습니다. 아니면, 유저 모드 프로그램이 16진수 문자열을 10 글자 길이의
형식의 값, 예를 들면, “0x12345678″로 쓸 수 있습니다. 이것은 pm_qos_update_request
호출로 변환됩니다.
목표 값의 유저 모드 요청을 지우려면, 간단히 디바이스 노드를 닫으세요.
2. PM QoS per-device 지연 프레임워크
각 개별 디바이스를 위한 성능 요청의 리스트는 취합된 목표 값으로 관리됩니다.
취합된 목표 값은 요청 리스트나 그 리스트의 개체로의 변경으로 갱신됩니다.
일반적으로 그 취합된 목표 값은 간단히 파라미터 리스트 개체 안에 잡힌 요청 값의
최고, 또는 최소 값입니다.
알림: 그 취합된 목표 값은 어토믹(atomic) 변수로 구현됩니다. 그래서 취합된 값을
읽는 것은 어떤 락킹 메카니즘도 필요 없습니다.
커널 모드로부터 이 인터페이스 사용은 다음과 같습니다:
int dev_pm_qos_add_request(device, handle, value):
는 개체 하나를 그 리스트 안으로 목표 값으로 식별된 디바이스를 위해 삽입할
것입니다. 이 리스트로의 변경 위해서 새로운 목표는 재계산되고, 어떤 등록된
통지자가 그 목표 값이 지금과 다를 때만 호출됩니다. dev_pm_qos의 클라이언트는
다른 dev_pm_qos API 함수들 안에서 추후에 사용될 때를 위해 그 핸들을 저장할
필요가 있습니다.
int dev_pm_qos_update_request(handle, new_value):
는 그 핸들이 가리키는 리스트 개체를 새로운 목표 값으로 갱신하고, 그 목표가
바뀌면 새로운 취합된 목표, 통지 트리 호출을 재계산합니다.
int dev_pm_qos_remove_request(handle):
는 개체를 제거합니다. 제거 후에는 취합된 목표를 갱신하고, 그 목표가 요청 제거의
결과로 바뀌면, 통지 트리를 호출할 것입니다.
s32 dev_pm_qos_read_value(device):
주어진 디바이스의 제약 사항 라스트를 위한 취합 값을 반환합니다.
통지 메카니즘:
per-device PM QoS 프레임워크는 2개의 다르고 구별되는 통지 트리를 가집니다:
per-device 통지 트리와 전역 통지 트리
int dev_pm_qos_add_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 추가합니다.
디바이스 제약사항 리스트의 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_notifier(device, notifier):
디바이스를 위한 통지 콜백 함수를 제거합니다.
int dev_pm_qos_add_global_notifier(notifier):
프레임워크의 전역 통지 트리 안에 통지 콜백 함수를 추가합니다.
어떤 디바이스를 위한 취합된 값이 바뀔 때, 콜백이 호출됩니다.
int dev_pm_qos_remove_global_notifier(notifier):
프레임워크의 전역 통지 트리로부터 통지 콜백 함수를 제거합니다.
유저모드에서는:
per-device 지연 제약 사항으로의 유저 공간 접근을 위한 API는 아직 제공되지
않습니다. – 아직 토의 중.

[Linux:Kernel] CPU 토폴로지

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/cputopology.txt

번역: 양정석(dasomoli@gmailREMOVETHIS.com)

CPU 토폴로지는 sysfs를 통해 노출됩니다. 항목(속성들)은 /proc/cpuinfo와
유사합니다.

1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:

        cpuX의 물리적인 패키지 ID. 일반적으로 물리적인 소켓 번호에
        해당하지만, 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

2) /sys/devices/system/cpu/cpuX/topology/core_id:

        cpuX의 CPU 코어 ID. 일반적으로 (커널의 것 보다는) 하드웨어
        플랫폼의 식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라
        다릅니다.

3) /sys/devices/system/cpu/cpuX/topology/book_id:

        cpuX의 Book ID. 일반적으로 (커널의 것 보다는) 하드웨어 플랫폼의
        식별자입니다. 실제 값은 아키텍처와 플랫폼에 따라 다릅니다.

4) /sys/devices/system/cpu/cpuX/topology/thread_siblings:

        cpuX와 같은 코어 내부의 cpuX의 하드웨어 스레드들의 내부 커널 맵

5) /sys/devices/system/cpu/cpuX/topology/core_siblings:

        같은 물리적 패키지 ID(physical_package_id) 내부의 cpuX의
        하드웨어 스레드들의 내부 커널 맵

6) /sys/devices/system/cpu/cpuX/topology/book_siblings:

        같인 Book ID(book_id) 내부의 cpuX의 하드웨어 스레드들의 내부
        커널 맵

아키텍처에 자연스러운 방법으로 구현하기 위해서, 새로운 소스 파일,
drivers/base/topology.c는 4 에서 6 개의 속성들을 드러냅니다. sysfs
파일들에 관련된 두 book 은 CONFIG_SCHED_BOOK 이 선택되었을 경우에만
생성될 것입니다.

이 기능을 지원하는 아키텍처를 위해서, include/asm-XXX/topology.h 안에
이들 매크로들 중 몇가지가 정의되어야만 합니다:
#define topology_physical_package_id(cpu)
#define topology_core_id(cpu)
#define topology_book_id(cpu)
#define topology_thread_cpumask(cpu)
#define topology_core_cpumask(cpu)
#define topology_book_cpumask(cpu)

**_id의 타입은 int 입니다.
sibling의 타입은 (const) struct cpumask * 입니다.

모든 아키텍처에 일관되도록, include/linux/topology.h 는
include/asm-XXX/topoloty.h 에서 정의하지 않는 위들 매크로 중 무엇을 위한
기본 정의를 제공합니다:
1) physical_package_id: -1
2) core_id: 0
3) thread_siblings: 그냥 주어진 CPU
4) core_siblings: 그냥 주어진 CPU

Book(CONFIG_SCHED_BOOK)을 지원하지 않는 아키텍처에는 topology_book_id() 와
topology_book_cpumask() 의 기본 정의가 없습니다.
추가적으로, CPU 토폴로지 정보는 /sys/devices/system/cpu 아래에서 제공되고,
이들 파일을 포함합니다. 출력의 내부 소스는 브라켓들(“[]”) 안에 있습니다.

    kernel_max: 커널 설정[NR_CPUS-1]에서 허용되는 최고 CPU 인덱스

    offline:    핫플러그 오프(HOTPLUGGED off:cpu-hotplug.txt 참고)되었거나,
                커널 설정(위의 kernel_max)에서 허용되는 CPU들의 제한을
                초과핬기 때문에 온라인이 아닌 CPU들.
                [~cpu_online_mask + cpus >= NR_CPUS]

    online:     온라인이고 스케줄 중인 CPU들 [cpu_online_mask]

    possible:   자원을 할당받았고, 지금 존재하면 온라인이 될 수 있는
                CPU들. [cpu_possible_mask]

    present:    시스템에 현재 존재하고 있는 것으로 식별된 CPU들.
                [cpu_present_mask]

위 출력의 형식은 cpulist_parse()[<linux/cpumask.h>]와 호환됩니다.
아래 예제가 있습니다.

이 예제에서, 64개의 CPU들이 시스템 내부에 있지만, CPU 32-63은 32로
된 NR_CPUS 설정 옵션에 의해 0..31 로 제한된 커널 최고값을 초과했습니다.
CPU 2와 4-31들은 온라인이 아니지만, 존재(present)하고, 가능(possbile)하므로
온라인이 될 수 있습니다.

     kernel_max: 31
        offline: 2,4-31,32-63
         online: 0-1,3
       possible: 0-31
        present: 0-31

이 예제에서, NR_CPUS 설정 옵션은 128이지만, 커널은 possible_cpus=144로
시작되었습니다. 시스템 내에 4개의 CPU가 있고, cpu2는 수동으로 오프라인이
되었습니다(그리고, 그 하나의 CPU만 온라인이 될 수 있습니다).

     kernel_max: 127
        offline: 2,4-127,128-143
         online: 0-1,3
       possible: 0-127
        present: 0-3

possible_cpus=숫자 시작 파라미터는 다양한 cpumask 의 더 많은 정보로
좋은 cpu-hotplug.txt 를 보세요.