linux2025. 12. 28. 18:39
#!/bin/bash


echo 0 > /sys/kernel/debug/tracing/tracing_on
echo "ftrace off"
sleep 3
cp /sys/kernel/debug/tracing/trace .
mv trace ftrace_log

 

 

setter

#!/bin/bash


echo 0 > /sys/kernel/debug/tracing/tracing_on
sleep 1

echo 0 > /sys/kernel/debug/tracing/events/enable
sleep 1
echo "events disabled"

#echo secondary_start_kernel > /sys/kernel/debug/tracing/set_ftrace_filter
#sleep 1
#echo "set_ftrace_filter init"


echo function > /sys/kernel/debug/tracing/current_tracer
sleep 1
echo "function tracer enabled"

#echo rpi_get_interrupt_info > /sys/kernel/debug/tracing/set_ftrace_filter
#echo show_interrupts > /sys/kernel/debug/tracing/set_ftrace_filter
echo zoneinfo_show > /sys/kernel/debug/tracing/set_ftrace_filter
sleep 1
echo "set_ftrace_filter enabled"

#echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_entry/enable
#echo 1 > /sys/kernel/debug/tracing/events/irq/irq_handler_exit/enable

echo "event enabled"

echo 1 > /sys/kernel/debug/tracing/options/func_stack_trace
echo "function stack trace enabled"

echo 1 > /sys/kernel/debug/tracing/options/func_stack_trace
echo 1 > /sys/kernel/debug/tracing/options/sym-offset
echo "function stack trace enabled"


echo 1 > /sys/kernel/debug/tracing/tracing_on
echo "tracing on"

getter

 

 

Posted by easy16
linux2025. 12. 28. 16:53

/proc/meminfo의 값들을 계산할 때도 zoneinfo에서 사용되는 page 정보들을 이용해 계산되는가

 
 
 
 

네, 정확히 맞습니다!

/proc/meminfo의 값들은 /proc/zoneinfo의 페이지 정보들을 집계해서 계산됩니다.

/proc/meminfo의 주요 항목 계산

 
 
c
// linux/mm/page_alloc.c에서
si_meminfo() 함수가 zoneinfo를 읽어서 meminfo 계산

MemTotal = Σ(모든 zone의 managed)
MemFree = Σ(모든 zone의 free)
MemAvailable = MemFree + 회수 가능한 페이지들
MemUsed = MemTotal - MemFree
```

## 당신의 RPi4 데이터로 검증
```
/proc/zoneinfo에서:
Node 0, DMA:      managed = 220735,  free = 215866
Node 0, DMA32:    managed = 253815,  free = 133994
Node 1, DMA32:    managed = 497449,  free = 380141
                  ──────────────────  ──────────────
                  합계 = 971999       합계 = 730001

↓ 이를 /proc/meminfo로 변환 ↓

MemTotal = 971999 × 4 = 3,887,996 KB
MemFree = 730001 × 4 = 2,920,004 KB

/proc/meminfo의 다른 항목들도 zoneinfo 기반

 
 
bash
MemTotal       = Σ managed
MemFree        = Σ free
MemAvailable   = MemFree + (회수 가능한 파일 캐시)
Buffers        = 버퍼 캐시 (zoneinfo의 nr_file_pages 관련)
Cached         = 파일 캐시 (zoneinfo의 nr_active_file + nr_inactive_file)
Active         = Σ nr_active_anon + nr_active_file
Inactive       = Σ nr_inactive_anon + nr_inactive_file
AnonPages      = Σ nr_anon_pages
Slab           = Σ (nr_slab_reclaimable + nr_slab_unreclaimable)

커널 소스코드

 
 
c
// mm/page_alloc.c
void si_meminfo(struct sysinfo *val)
{
    unsigned long pages = 0;
    
    // 모든 zone 순회
    for_each_zone(zone) {
        pages += zone->managed_pages;      // MemTotal 계산
    }
    val->totalram = pages;
    
    // MemFree 계산
    val->freeram = global_node_page_state(NR_FREE_PAGES);
    
    // 기타 항목들...
}

실제 확인 방법

 
 
bash
# zoneinfo의 managed 합계
awk '/managed/{sum+=$2} END {print "MemTotal = " sum*4 " KB"}' /proc/zoneinfo

# zoneinfo의 free 합계
awk '/pages free/{sum+=$3} END {print "MemFree = " sum*4 " KB"}' /proc/zoneinfo

# /proc/meminfo 값과 비교
grep "MemTotal\|MemFree" /proc/meminfo
```

## 더 상세한 대응관계
```
/proc/meminfo 항목          zoneinfo 출처
─────────────────────────────────────────────
MemTotal                    Σ managed
MemFree                     Σ free
MemAvailable                MemFree + 회수 가능
Buffers                     (버퍼 캐시)
Cached                      Σ nr_file_pages
Active(anon)                Σ nr_active_anon
Inactive(anon)              Σ nr_inactive_anon
Active(file)                Σ nr_active_file
Inactive(file)              Σ nr_inactive_file
AnonPages                   Σ nr_anon_pages
Slab                        Σ nr_slab_reclaimable + 
                              nr_slab_unreclaimable
KernelStack                 Σ nr_kernel_stack
PageTables                  Σ nr_page_table_pages
```

## 계층 관계
```
/proc/zoneinfo (세부 정보)
        ↑
        │ (커널이 집계)
        ↓
/proc/meminfo (통합 정보)
        ↑
        │ (사용자가 조회)
        ↓
free, top 등의 도구

결론:

  • ✅ /proc/meminfo는 /proc/zoneinfo 정보를 실시간으로 집계해서 만들어짐
  • ✅ zoneinfo의 managed/free 합계 × 4K = meminfo의 MemTotal/MemFree
  • ✅ 둘 다 같은 커널 메모리 관리 데이터 구조에서 나옴

'linux' 카테고리의 다른 글

ftrace script  (0) 2025.12.28
/proc/zoneinfo 해석 방법  (0) 2025.12.28
zone, free_area, list_head[MIGRATE_TYPES] 관련  (0) 2025.12.28
raspberry pi 4 커널 빌드 및 교체 시 주의 사항  (0) 2025.12.26
gst와 omx IL의 관계  (0) 2022.11.03
Posted by easy16
linux2025. 12. 28. 16:25

/proc/zoneinfo 해석 가이드

핵심 항목만 보기

복잡해 보이지만, 실제로 중요한 항목은 몇 개입니다.

1단계: 노드(Node)와 존(Zone) 파악

 
 
Node 0, zone DMA      ← NUMA Node 0의 DMA 영역
Node 0, zone DMA32    ← NUMA Node 0의 DMA32 영역
Node 1, zone DMA32    ← NUMA Node 1의 DMA32 영역

당신의 경우: 2개 노드, 각각 DMA + DMA32 영역만 사용

2단계: 각 Zone의 메모리 상태

RPi4 기준으로 중요한 항목:

 
 
Node 0, zone DMA
  pages free     215866        ← 사용 가능한 페이지 수
        managed  220735        ← 관리 중인 전체 페이지 수
        cma      131072        ← CMA 영역 (카메라/GPU용)
  nr_free_cma  126266          ← 사용 가능한 CMA 페이지

간단한 계산:

 
 
215866 pages × 4KB = 약 843MB 자유 메모리 (DMA 존)
126266 CMA pages × 4KB = 약 492MB (GPU/카메라용 예약)

3단계: 간단한 해석 패턴

 
 
bash
# 이 명령으로 깔끔하게 보기
grep -E "zone|free|managed|cma" /proc/zoneinfo
```

**출력 예:**
```
Node 0, zone      DMA
  pages free     215866        # ✓ 자유 메모리
        managed  220735        # 관리 중
        cma      131072        # GPU 예약
  nr_free_cma  126266          # ✓ 사용 가능한 CMA

Node 0, zone    DMA32
  pages free     133994        # ✓ 자유 메모리
        managed  253815        # 관리 중
```

## RPi4 당신의 상황 분석
```
Node 0 (CPU 0,1 담당):
  DMA:   215,866 pages free (약 843MB) - GPU 공유
  DMA32: 133,994 pages free (약 523MB)
  
Node 1 (CPU 2,3 담당):
  DMA32: 380,141 pages free (약 1.4GB)

전체: 약 2.7GB 자유 메모리
```

## 추가 유용한 해석

**per-cpu pageset (CPU별 캐시):**
```
pagesets
  cpu: 0
        count: 62           ← CPU 0의 로컬 캐시 페이지 수
        high:  290         ← 상한선 (초과하면 buddy로 반환)
        batch: 63          ← 배치 크기
  cpu: 1
        count: 0           ← CPU 1은 로컬 캐시 비어있음
```

**최소/최대 임계값:**
```
min:  930    ← 이 이하면 메모리 부족
low:  1162   ← kswapd 깨우는 수준
high: 1394   ← 여유 있는 수준

한 줄로 상태 확인

 
 
bash
# 전체 자유 메모리 계산
awk '/pages free/{sum+=$3} END {print sum*4 "KB =" sum/256 "MB"}' /proc/zoneinfo
```

**당신의 시스템:**
```
약 750,000 pages × 4KB = 약 2.9GB 자유 메모리

스크립트로 간단하게 보기

 
 
bash
#!/bin/bash
echo "=== Zone 메모리 상태 ==="
awk '/^Node/ {node=$2} /^  zone/ {zone=$2} /pages free/ {free=$3} /managed/ {managed=$2} /nr_free_cma/ {cma=$2} /^$/ {if(node) printf "Node %s, %s: Free=%dMB (CMA=%dMB), Total=%dMB\n", node, zone, free*4/256, cma*4/256, managed*4/256}' /proc/zoneinfo

가장 간단한 방법

 
 
bash
# 1. 전체 자유 메모리만 보기
free -h

# 2. Zone별 상세는 이 부분만 보기
grep -A3 "^Node" /proc/zoneinfo | grep -E "free|managed"

결론:

  • free = 사용 가능한 페이지 수
  • managed = 관리 중인 전체 페이지 수
  • cma = GPU/카메라용 예약 영역
  • 나머지는 대부분 무시해도 됨

 

 

 

nr_은 무엇의 약자야? , managed는 어떤 의미인지 모르겠어 사용 중인거야 사용 가능한거야

오후 4:27
 
 
 
 

nr_과 managed의 의미

nr_ = "number of"의 약자

 
 
c
nr_free_pages   = number of free pages (자유 페이지의 수)
nr_dirty        = number of dirty pages (더티 페이지의 수)
nr_slab_reclaimable = number of slab reclaimable (회수 가능한 slab의 수)
```

**정리:**
- `nr_` = **개수/숫자**를 나타내는 접두사
- 항상 "몇 개인가"를 의미

---

## managed = 커널이 관리하는 페이지
```
물리 메모리
├─ 예약된 영역 (BIOS, 부트로더 등) - 커널이 건드리지 않음
├─ managed ← 커널이 관리할 수 있는 영역
│   ├─ free (사용 가능)
│   ├─ used (사용 중)
│   └─ ...
└─ (기타)
```

**쉽게 말하면:**
- **managed** = 커널이 할당/관리하는 페이지 풀
- **free** = managed 중에서 **지금 비어있는** 것

---

## 구체적 예시
```
Node 0, zone DMA
  pages free     215866    ← 현재 비어있는 페이지
        managed  220735    ← 커널이 관리할 수 있는 전체 페이지
        
사용 중인 페이지 = managed - free
               = 220735 - 215866
               = 4869 pages (약 19MB 사용 중)

다른 항목들과의 관계

 
 
c
struct zone {
    // 페이지 상태 분류
    managed          // 커널이 관리 가능한 전체 페이지
    ├─ free          // 사용 가능한 페이지 (할당 대기 중)
    └─ used (암묵적)
        ├─ nr_active_anon        // 활성 익명 페이지 (메모리)
        ├─ nr_inactive_anon      // 비활성 익명 페이지
        ├─ nr_active_file        // 활성 파일 캐시
        ├─ nr_inactive_file      // 비활성 파일 캐시
        ├─ nr_kernel_stack       // 커널 스택
        ├─ nr_page_table_pages   // 페이지 테이블
        └─ ... (기타 사용 중인 페이지)
};
```

## 당신의 RPi4 데이터로 분석
```
Node 0, zone DMA
  managed: 220735 pages (전체 관리 페이지)
  free:    215866 pages (현재 사용 가능)
  
  사용 중: 220735 - 215866 = 4869 pages
         = 약 19MB 사용 중
         
  내역:
    nr_active_anon:     0      (익명 페이지)
    nr_active_file:     0      (파일 캐시)
    nr_kernel_stack:    ?      (커널 스택)
    ... (합쳐서 4869)

Node 0, zone DMA32
  managed: 253815 pages (전체 관리 페이지)
  free:    133994 pages (현재 사용 가능)
  
  사용 중: 253815 - 133994 = 119821 pages
         = 약 467MB 사용 중
         
  내역:
    nr_zone_active_anon:  22471  (활성 메모리)
    nr_zone_inactive_anon: 0
    nr_zone_active_file:  32489  (파일 캐시)
    nr_zone_inactive_file: 45782
    ... (합쳐서 119821)
```

## 메모리 상태 정리

| 항목 | 의미 | 상태 |
|------|------|------|
| **managed** | 커널이 관리 가능 | 포함된 범위 정의 |
| **free** | 현재 비어있음 | ✓ 할당 가능 |
| **used** (managed - free) | 현재 사용 중 | 이미 할당됨 |
| **nr_active_anon** | 활성 메모리 페이지 | used에 포함 |
| **nr_active_file** | 활성 캐시 페이지 | used에 포함 |

## 간단한 공식
```
managed = free + used
        = free + (nr_active_anon + nr_inactive_anon + 
                  nr_active_file + nr_inactive_file + 
                  nr_kernel_stack + ...)

결론:

  • nr_ = "개수" (number of)
  • managed = 커널이 관리하는 페이지 풀의 크기
  • free = managed 중 현재 비어있는 것
  • used = managed 중 현재 사용 중인 것
 
 
 
 
 

present와 managed 차이

오후 4:29
 
 
 
 

present vs managed 차이

핵심

 
 
present  = 물리적으로 실제 존재하는 페이지
managed  = 커널이 실제로 관리/할당할 수 있는 페이지

구체적 차이

 
 
physical memory (물리 메모리)
│
├─ present: 242688 pages (실제 존재)
│  │
│  ├─ reserved (예약됨 - 커널이 건드리지 않음)
│  │  ├─ BIOS 영역
│  │  ├─ 부트로더
│  │  └─ 펌웨어 (RPi4의 GPU 펌웨어)
│  │
│  └─ manageable (관리 가능)
│     └─ managed: 220735 pages ← 커널이 할당/관리
│        ├─ free: 215866 (사용 가능)
│        └─ used: 4869 (사용 중)

당신의 RPi4 데이터로 보기

 
 
Node 0, zone DMA
  present  242688    ← 실제 존재하는 물리 페이지
  managed  220735    ← 커널이 관리하는 페이지
  
  예약됨 = present - managed
        = 242688 - 220735
        = 21953 pages (약 85MB)
        
이 85MB는 GPU, 부트로더, BIOS 등이 사용

Node 0, zone DMA32
  present  262144    ← 실제 존재
  managed  253815    ← 커널이 관리
  
  예약됨 = 262144 - 253815
        = 8329 pages (약 32MB)

왜 managed < present일까?

RPi4 특성:

 
 
present = 242688 pages
  ├─ GPU 펌웨어 영역 (RPi4는 ARM CPU와 GPU 공유)
  ├─ 부트로더
  ├─ 디바이스 트리 (device tree)
  ├─ BIOS/UEFI 영역
  └─ managed: 220735 pages만 Linux가 관리

일반 PC vs RPi4:

 
 
일반 PC:
  present ≈ managed (대부분 예약 영역 없음)
  
RPi4:
  present > managed (GPU가 메모리 독점, 공유 메모리 존재)
  present - managed = 약 10% (GPU 펌웨어용)

메모리 계층 구조 (정확한 버전)

 
 
Physical Memory (물리적으로 존재)
│
├─ Node 0, zone DMA
│  │
│  ├─ present: 242688 pages
│  │  │
│  │  ├─ reserved (커널이 관리 안 함)
│  │  │  └─ 21953 pages (GPU, 펌웨어 등)
│  │  │
│  │  └─ managed: 220735 pages ← 커널이 관리
│  │     ├─ free: 215866 pages (할당 가능)
│  │     └─ used: 4869 pages (사용 중)
│  │        ├─ nr_kernel_stack
│  │        ├─ nr_page_table_pages
│  │        └─ ...
│  │
│  └─ cma: 131072 pages (GPU용 연속 메모리, managed에 포함)
│     ├─ nr_free_cma: 126266 (사용 가능)
│     └─ used_cma: ~5000
│
└─ Node 0, zone DMA32
   ├─ present: 262144
   └─ managed: 253815
      ├─ free: 133994
      └─ used: 119821

spanned vs present vs managed

 
 
Node 0, zone DMA
  spanned: 262144   ← 이 zone이 담당하는 주소 범위의 페이지 수
  present: 242688   ← 그 중 실제 존재하는 페이지 수
  managed: 220735   ← 그 중 커널이 관리하는 페이지 수
  
spanned > present (어떤 주소는 비어있을 수 있음)
present > managed (일부는 예약됨)

공식

 
 
c
spanned   = zone의 주소 범위로 계산한 페이지 수
present   = spanned 중 실제 물리 메모리가 있는 페이지
managed   = present 중 커널이 할당 가능한 페이지
free      = managed 중 현재 비어있는 페이지

따라서:
spanned ≥ present ≥ managed ≥ free

요약표

항목의미예시
spanned 이론적 범위 262144 pages
present 실제 존재 242688 pages
managed 커널 관리 220735 pages
free 현재 사용 가능 215866 pages

결론:

  • present = 물리적으로 "실제 있는" 페이지
  • managed = 물리적으로 있으면서 "커널이 관리하는" 페이지
  • RPi4에서 present - managed ≈ GPU 펌웨어용 메모리

'linux' 카테고리의 다른 글

ftrace script  (0) 2025.12.28
/proc/meminfo와 zoneinfo의 관계  (0) 2025.12.28
zone, free_area, list_head[MIGRATE_TYPES] 관련  (0) 2025.12.28
raspberry pi 4 커널 빌드 및 교체 시 주의 사항  (0) 2025.12.26
gst와 omx IL의 관계  (0) 2022.11.03
Posted by easy16
linux2025. 12. 28. 16:20

 

 

Q.free_area는 4K의 승수별로 존재, list_head는 type 별 리스트를 가진다고 이해하면 되나

 

정확합니다! 당신의 이해가 맞습니다.

정리

free_area[order]의 구조:

free_area[0]  (2^0 = 1 page = 4KB)
├─ free_list[MIGRATE_UNMOVABLE]  → [page] → [page] → ...
├─ free_list[MIGRATE_MOVABLE]    → [page] → [page] → ...
├─ free_list[MIGRATE_RECLAIMABLE]→ [page] → [page] → ...
├─ free_list[MIGRATE_HIGHATOMIC] → [page] → ...
└─ free_list[MIGRATE_CMA]        → [page] → ...

free_area[1]  (2^1 = 2 pages = 8KB)
├─ free_list[MIGRATE_UNMOVABLE]  → [page] → [page] → ...
├─ free_list[MIGRATE_MOVABLE]    → [page] → [page] → ...
├─ free_list[MIGRATE_RECLAIMABLE]→ ...
├─ free_list[MIGRATE_HIGHATOMIC] → ...
└─ free_list[MIGRATE_CMA]        → ...

free_area[2]  (2^2 = 4 pages = 16KB)
├─ free_list[...]
└─ ...

...

free_area[10] (2^10 = 1024 pages = 4MB)
├─ free_list[...]
└─ ...

코드로 보면

struct zone {
    struct free_area free_area[MAX_ORDER];  // MAX_ORDER = 11
};

struct free_area {
    struct list_head free_list[MIGRATE_TYPES];  // MIGRATE_TYPES = 5
    unsigned long nr_free;
};

예시: 8KB 메모리 블록 찾기

// 8KB (2 pages) 크기의 MOVABLE 타입 메모리를 찾고 싶다면
struct list_head *target = &zone->free_area[1].free_list[MIGRATE_MOVABLE];
//                                          ↑                        ↑
//                                     order=1 (8KB)        type별 리스트
//                                    (2^1 page blocks)

할당/해제 관점

 
// 8KB 할당 요청이 오면
// → order=1, migratetype=MIGRATE_MOVABLE인 경우
// → zone->free_area[1].free_list[MIGRATE_MOVABLE]에서 페이지 블록 추출

// 8KB 메모리 해제
// → order=1, migratetype=MIGRATE_MOVABLE
// → zone->free_area[1].free_list[MIGRATE_MOVABLE]에 페이지 블록 추가
```

## 마이그레이션 타입 분리의 이점
```
같은 크기(order)여도 타입별로 분리:

free_area[1].free_list[MIGRATE_MOVABLE]    → 이동 가능한 8KB 블록들
free_area[1].free_list[MIGRATE_UNMOVABLE] → 이동 불가능한 8KB 블록들

→ 커널이 8KB 메모리를 할당할 때 UNMOVABLE 영역에서만 찾기
→ MOVABLE 영역을 보존 (메모리 압축/조각화 방지)

당신의 이해가 정확합니다!

  • ✅ 크기: 4KB의 승수별로 존재 (2^0, 2^1, ... 2^10)
  • ✅ 리스트: 각 크기별로 타입에 따른 5개의 리스트 보유
 
 
 
 
 

Q. 여기서 MIGRATE_TYPES는 zone의 종류와는다른거야?

 

네, 완전히 다른 개념입니다!

구분

MIGRATE_TYPES = 페이지의 이동 가능성 속성

#define MIGRATE_UNMOVABLE       0  // 커널이 사용, 이동 불가
#define MIGRATE_MOVABLE         1  // 사용자 프로세스, 이동 가능
#define MIGRATE_RECLAIMABLE     2  // 캐시, 회수 가능
#define MIGRATE_HIGHATOMIC      3  // 원자적 할당 예약
#define MIGRATE_CMA             4  // Contiguous Memory Allocator

Zone = 메모리의 물리적 위치 기준

enum zone_type {
    ZONE_DMA,        // 0-16MB (DMA 가능)
    ZONE_DMA32,      // 0-4GB (32bit DMA)
    ZONE_NORMAL,     // 일반 메모리
    ZONE_HIGHMEM,    // 고위 메모리 (32bit)
    ZONE_MOVABLE,    // 이동 가능 영역
    // ...
};

struct zone {
    struct free_area free_area[MAX_ORDER];
    // ...
};
```

## 계층 구조
```
Node (NUMA)
  ↓
Zone (DMA, NORMAL, HIGHMEM, ...)
  ↓
free_area[0..10] (크기별: 4KB, 8KB, 16KB, ..., 4MB)
  ↓
free_list[MIGRATE_TYPES] (타입별: UNMOVABLE, MOVABLE, ...)
  ↓
[페이지] → [페이지] → [페이지] → ...

구체적 예시

// ZONE_NORMAL에서 8KB 메모리 할당

struct zone *zone = &NODE_DATA(0)->node_zones[ZONE_NORMAL];
//                                           ↑
//                                     물리적 위치 (Zone)

struct free_area *area = &zone->free_area[1];
//                                        ↑
//                                    크기 (8KB = 2^1)

struct list_head *list = &area->free_list[MIGRATE_MOVABLE];
//                                         ↑
//                                 이동 가능성 (Type)

// 실제 페이지 추출
page = list_first_entry_or_null(list, struct page, lru);
```

## 메모리 레이아웃
```
ZONE_DMA (0-16MB)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  ├─ free_list[MIGRATE_MOVABLE]
│  └─ ...
├─ free_area[1]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

ZONE_NORMAL (16MB-4GB)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  ├─ free_list[MIGRATE_MOVABLE]
│  └─ ...
├─ free_area[1]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

ZONE_HIGHMEM (4GB 이상)
├─ free_area[0]
│  ├─ free_list[MIGRATE_UNMOVABLE]
│  └─ ...
└─ ...

커널 코드에서

// mm/page_alloc.c
static struct page *
get_page_from_freelist(gfp_t gfp_mask, unsigned int order,
                       int alloc_flags, const struct alloc_context *ac)
{
    struct zoneref *z;
    struct zone *zone;
    struct page *page = NULL;
    
    // 1. Zone 순회 (DMA → NORMAL → ...)
    for_each_zone_zonelist_nodemask(zone, z, ac->zonelist,
                                    ac->highest_zoneidx, ac->nodemask) {
        // 2. free_area[order] 선택
        // 3. free_list[migratetype] 선택
        // 4. 페이지 추출
    }
    
    return page;
}

정리

항목기준종류
Zone 물리적 위치 DMA, NORMAL, HIGHMEM, ...
free_area[order] 메모리 크기 4KB, 8KB, 16KB, ..., 4MB
MIGRATE_TYPES 페이지 속성/이동성 UNMOVABLE, MOVABLE, ...

MIGRATE_TYPES는 Zone과 무관하게, 각 Zone의 모든 free_area에서 타입별로 페이지를 분류하는 것입니다!

'linux' 카테고리의 다른 글

/proc/meminfo와 zoneinfo의 관계  (0) 2025.12.28
/proc/zoneinfo 해석 방법  (0) 2025.12.28
raspberry pi 4 커널 빌드 및 교체 시 주의 사항  (0) 2025.12.26
gst와 omx IL의 관계  (0) 2022.11.03
fs.protected_regular  (0) 2022.10.04
Posted by easy16
linux2025. 12. 26. 22:12

 

config 생성 및 커널 이미지 빌드는 아래 스크립트의 명령어 참조

아래와 같이 OUTPUT를 O 옵션으로 지정하면, 커널 코드 내 변경 없이 깔끔하게 빌드할 수 있는 장점이 있음

 

윈도우 wsl에서 cross compile 환경으로 빌드를 하다보니, 가이드 대로 하는게 불가능함.

편의를 위해 먼저 rpi4의 root 패스워드를 지정하고 dtb* 및 Image 만 복사하면 될 줄 알았는데, 커널 부팅이 안된다.

다행이도 윈도우에서 kernel8.img를 간단히 복사 가능하므로 복구해주고..

 

결과물 중, vmlinux는 add2line이나 gdb 사용을 위한 이미지로 부팅이 불가

Image는 raw 형태로 대략 26M쯤 나간다.

이를  z 또는 lz 형태로 압축하면 8~9M로 줄고, 이게 기존 rpi4에서 배포된 이미지로 보임. (귀찮으니 확인은 생략)

 

 

 

커널 버전이 달라서 커널 모듈이 모두 재컴파일 필요함. (처음부터 버전을 맞춰서 구할 수 있으면 좋았을텐데)

 

매우 귀찮지만, modules_install을 wsl내 임의의 경로에서 진행

타겟에서 lsblk을 실행하면, boot는 mmcblock1 root는 2에 있다는게 확인 가능하므로 가이드대로 적당히 마운트 후 복사하면 됨.

이후 tar로 묶어 타겟의 /lib/modules 경로에서 풀고 재부팅하면, 동작이 가능하다.

 

 

 

장난감 완성~

 

 

#!/bin/bash
#
#
#KERNEL_TOP_PATH="$( cd "$(dirname "$0")" ; pwd -P )"
KERNEL_TOP_PATH="$( cd "$(dirname "$0")" ; pwd -P )"
#KERNEL_TOP_PATH="/root/workspace/project/rpi4/linux"
OUTPUT="$KERNEL_TOP_PATH/out"
BUILD_LOG=$KERNEL_TOP_PATH/rpi_build_log.txt
echo "$OUTPUT"

cd linux
#if build error happens
#make ARCH=arm64 mrproper -j10
KERNEL=kernel8
make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) bcm2711_defconfig
#make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Image modules dtbs 2>&1 | tee $BUILD_LOG
#tar the output dir in /lib/modules/xxx and scp to target
make O=$OUTPUT ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) INSTALL_MOD_PATH=../out/mnt/root modules_install

 

 

커널 다운로드 및 빌드 가이드는 다음 링크 참조

https://www.raspberrypi.com/documentation/computers/linux_kernel.html

 

The Linux kernel - Raspberry Pi Documentation

The official documentation for Raspberry Pi computers and microcontrollers

www.raspberrypi.com

 

 

 

 

'linux' 카테고리의 다른 글

/proc/zoneinfo 해석 방법  (0) 2025.12.28
zone, free_area, list_head[MIGRATE_TYPES] 관련  (0) 2025.12.28
gst와 omx IL의 관계  (0) 2022.11.03
fs.protected_regular  (0) 2022.10.04
KMS, DRM, DRI 에 대한 개요  (0) 2022.09.10
Posted by easy16
linux2022. 11. 3. 21:58



gst-openmax
openMAX IL
https://freedesktop.org/wiki/GstOpenMAX/

openMAX
https://www.khronos.org/api/openmax/il


gstreamer1

https://medium.com/may-i-lab/gstreamer-gstreamer-%EA%B8%B0%EC%B4%88-da5015f531fc


gstreamer2
https://gstreamer.freedesktop.org/features/index.html

GStreamer can bridge to other multimedia frameworks in order to reuse existing components (e.g. codecs) and use platform input/output mechanisms:

Linux/Unix: OpenMAX-IL (via gst-omx)
Windows: DirectShow
Mac OS X: QuickTime

 


GStreamer + OpenMAX-IL
https://www.khronos.org/files/openmax/whitepapers/OpenMAX_IL_with_GSstreamer.pdf

'linux' 카테고리의 다른 글

zone, free_area, list_head[MIGRATE_TYPES] 관련  (0) 2025.12.28
raspberry pi 4 커널 빌드 및 교체 시 주의 사항  (0) 2025.12.26
fs.protected_regular  (0) 2022.10.04
KMS, DRM, DRI 에 대한 개요  (0) 2022.09.10
wayland, x-server 관련  (0) 2022.09.10
Posted by easy16
linux2022. 10. 4. 21:13

 

root로 충분한 권한을 가졌음에도 파일에 대한 write permission이 없는 경우가 있다.

 

 

 

su max
touch /tmp/test.txt
chmod 777 /tmp/test.txt

su root
chown max:root /tmp/test.txt

# ls -l /tmp/test.txt 
-rwxrwxrwx 1 max root 0 26. Feb 12:08 test.txt

# echo "foobar" > /tmp/test.txt
bash: /tmp/test.txt: Permission denied

 

 

 

Disallows open of FIFOs or regular files not owned by the user in world writable sticky directories, unless the owner is the same as that of the directory or the file is opened without the O_CREAT flag. The purpose is to make data spoofing attacks harder. .

 

 

 

검색을 해보니 fs.protected_regular 값에 따라 동작이 달라질 것으로 보인다.

sysctl fs.protected_regular=0

 

 

$ su - root
# sysctl fs.protected_regular
fs.protected_regular = 1
# cd /
# mkdir test
# chmod 1777 test
# su - otheruser
$ echo hello >/test/somefile
$ exit
logout
# cat /test/somefile
hello
# ls -lah test/somefile
-rw-r--r-- 1 otheruser otheruser 6 Feb 26 17:21 test/somefile
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# sysctl fs.protected_regular=0
fs.protected_regular = 0
# echo root >>test/somefile
# cat /test/somefile
hello
root
# sysctl fs.protected_regular=1
fs.protected_regular = 1
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# chmod 0777 /test/
# echo root >>test/somefile
# cat test/somefile 
hello
root
root

 

하기 링크 참조..


https://unix.stackexchange.com/questions/691441/root-cannot-write-to-file-that-is-owned-by-regular-user
https://unix.stackexchange.com/questions/503111/group-permissions-for-root-not-working-in-tmp

'linux' 카테고리의 다른 글

raspberry pi 4 커널 빌드 및 교체 시 주의 사항  (0) 2025.12.26
gst와 omx IL의 관계  (0) 2022.11.03
KMS, DRM, DRI 에 대한 개요  (0) 2022.09.10
wayland, x-server 관련  (0) 2022.09.10
GPL ko(kernel object) 배포 관련  (0) 2022.09.10
Posted by easy16
linux2022. 9. 10. 12:29

 

아래 사이트에 설명을 다독할 필요가 있음.

특히나  /dev/fbdev 와 /dev/dri/cardX를 사용하는 것에 대한 차이는 기억해 두자.

 

 

https://prographics.tistory.com/1 

'linux' 카테고리의 다른 글

gst와 omx IL의 관계  (0) 2022.11.03
fs.protected_regular  (0) 2022.10.04
wayland, x-server 관련  (0) 2022.09.10
GPL ko(kernel object) 배포 관련  (0) 2022.09.10
GPL 관련 tip  (0) 2022.09.10
Posted by easy16
linux2022. 9. 10. 12:27

 

 

Architecture만 확인하면 wayland는 x-server 및 compositor를 합한 구조로 더 나은 성능을 보여줄 것으로 보인다.

하지만 ubuntu user들의 글을 보면 wayland가 나온지 10여년이 지났으나 여전히 x-server에 비해 더 나은 성능을 보여주지는 못하고 있다는 의견이다. (기존 Library 및 GPU에 대한 지원등 넘어야할 산이 많은 듯 보인다.)

현재 최신 ubuntu에는 x-client를 지원하는 xwayland가 default 로 적용되어 있다고 한다.

 

참조  : 

https://wayland.freedesktop.org/architecture.html

https://wiki.ubuntu.com/Wayland

'linux' 카테고리의 다른 글

fs.protected_regular  (0) 2022.10.04
KMS, DRM, DRI 에 대한 개요  (0) 2022.09.10
GPL ko(kernel object) 배포 관련  (0) 2022.09.10
GPL 관련 tip  (0) 2022.09.10
custom vimrc  (0) 2022.07.05
Posted by easy16
linux2022. 9. 10. 12:20

 

 

 

Q. 디바이스 드라이버 모듈(ko 파일)로 배포할 경우 소스를 오픈해야하나요?

A. 리눅스 기본 커널 인터페이스를 이용하여 커널 모듈을 100% 자체 개발한 경우라면 해당 드라이버를 독점 코드라고 주장할 수 있다고 판단됩니다.

* 라이선스는 Proprietary 적용
다만, 리눅스 커널 디바이스 드라이버의 GPL 적용 이슈는 아직도 논의가 진행중인 내용으로 명확하게 GPL의 적용을 받는다 안받는다라고 답변 드리기에는 어려움이 있으므로 이점 참고하시기 바랍니다.

 

 

=> 논란이 있는 와중이나 대체로 driver에 대한 공개는 의무가 아닌 것으로 보인다.

 

https://www.oss.kr/oss_license_qna/show/e305f450-dbdd-4324-94ef-888fa13281ac?page=65 

'linux' 카테고리의 다른 글

KMS, DRM, DRI 에 대한 개요  (0) 2022.09.10
wayland, x-server 관련  (0) 2022.09.10
GPL 관련 tip  (0) 2022.09.10
custom vimrc  (0) 2022.07.05
git stash 참조  (0) 2022.06.30
Posted by easy16