Electronic Artist

NUMA

Jay.P Morgan — Thu, 23 Jul 2026 16:34:39 +0900

NUMA (Non-Uniform Memory Access)

NUMA: 하드웨어 토폴로지(Topology), ACPI SRAT/SLIT, pglist_data, 메모리 정책(Memory Policy)(mbind/set_mempolicy), Automatic NUMA Balancing, NUMA-aware 스케줄링, numactl, CXL, vNUMA를 다룹니다.

# 분산 및 클라우드 컴퓨팅

NUMA 하드웨어 토폴로지, ACPI 테이블 파싱, 커널 자료구조, 메모리 정책, Automatic NUMA Balancing, NUMA-aware 스케줄링, CXL 확장까지 — 비균일 메모리 접근 아키텍처를 소스 코드 수준에서 분석합니다.

관련 표준: ACPI 6.5 (SRAT/SLIT/HMAT 테이블), JEDEC DDR5 (메모리 채널 구조), CXL 3.1 (캐시일관성(Cache Coherency) 인터커넥트) — NUMA 토폴로지 탐색과 메모리 접근에 관련된 핵심 규격입니다. 종합 목록은 참고자료 — 표준 & 규격 섹션을 참고하세요.

참고: NUMA의 기초 개념과 pg_data_t 개요는 메모리 관리(Memory Management) — NUMA 섹션을, Hugepage와 NUMA 연동은 Huge Pages — NUMA 섹션을 참조하세요.

1. 초보자 가이드

전제 조건: 메모리 관리 개요와 CPU 캐시(Cache) 문서를 먼저 읽으세요. 메모리 서브시스템은 가상메모리(Virtual Memory)와 물리 메모리(Physical Memory) 정책이 동시에 동작하므로, 주소 변환(Address Translation)과 회수 정책을 같이 보는 관점이 필요합니다.

일상 비유: 이 개념은 여러 창고가 있는 공장에서 가까운 창고를 우선 쓰는 것과 비슷합니다. 가까운 창고물건이 더 빨리 오듯이, NUMA도 현재 CPU에 가까운 메모리 노드를 먼저 쓰는 편이 지연이 적습니다. # 컴퓨터 메모리

1.1 핵심 요약

• NUMA — 메모리 접근 시간이 CPU와 메모리의 물리적 위치에 따라 달라지는 아키텍처입니다.

• Node — CPU 소켓(Socket)과 로컬 메모리를 묶은 단위. 커널에서 pglist_data 구조체(Struct)로표현됩니다.

• SRAT/SLIT — ACPI 테이블로 NUMA 토폴로지(노드 구성)와 거리(접근 지연(Latency))를 커널에전달합니다.

• 메모리 정책 — mbind()/set_mempolicy()로 프로세스(Process)의 메모리 할당 노드를 제어합니다.

• NUMA Balancing — 커널이 자동으로 페이지(Page)를 자주 접근하는 CPU 노드로마이그레이션합니다.

1.2 단계별 이해

① 토폴로지 확인 — numactl --hardware로 시스템의 NUMA 노드 수, 각 노드의 CPU와 메모리 크기를확인합니다.

커널 함수: acpi_numa_init() → acpi_parse_srat()가 SRAT 테이블을 파싱하여 numa_meminfo에 노드 정보를저장합니다. # 컴퓨터 하드웨어

② 로컬 vs 원격 접근 — 같은 노드의 메모리 접근은 빠르고(~80ns), 다른 노드 접근은 느립니다(~140ns).

커널 구조체: numa_distance[][] 배열에 SLIT 기반 노드 간 거리가 저장됩니다. numastat으로 노드별 할당통계를 모니터링할 수 있습니다.

③ 정책 적용 — numactl --cpubind=0 --membind=0 ./app으로 특정 노드에 CPU와 메모리를 바인딩합니다.

커널 함수: do_set_mempolicy()가 struct mempolicy를 태스크(Task)에 설정하고, alloc_pages_mpol()이 할당 시정책을 적용합니다.

④ 커널 자동 밸런싱 — /proc/sys/kernel/numa_balancing으로 자동 마이그레이션을 활성화/비활성화합니다.

커널 함수: task_tick_numa() → task_numa_work() → VMA 스캔→ do_numa_page() → task_numa_fault() → migrate_misplaced_folio() 체인으로 페이지를 최적 노드로이동시킵니다.

2. NUMA 탄생 배경과 기초 개념

NUMA를 제대로 이해하려면 먼저 왜 NUMA가 필요하게 되었는지와 로컬/원격 메모리 접근이 실제로어떻게 다른지를 파악해야 합니다. 이 섹션에서는 기초 개념, 핵심 용어, 그리고 실제 성능 영향을 설명합니다. # 소프트웨어

2.1 UMA에서 NUMA로 — 확장성 한계의 해결

초창기 다중 프로세서 시스템은 UMA(Uniform Memory Access, 균일 메모리 접근) 구조를 사용했습니다. 모든 CPU가 하나의 공유 메모리 버스를 통해 동일한 메모리에 접근하므로 구현이 단순하고 프로그래밍모델도 직관적입니다. 그러나 CPU 수가 증가할수록 공유 버스(Bus) 경합(Contention)이 기하급수적으로증가하며, 8~16코어를 넘어서면 메모리 버스가 포화되어 추가 CPU가 오히려 전체 처리량을 떨어뜨립니다.

NUMA(Non-Uniform Memory Access, 비균일 메모리 접근)는 이 병목(Bottleneck)을 해결하기 위해 각 CPU 소켓(또는 CPU 그룹)에 자신만의 로컬 메모리를 독립적으로 붙이는 방식으로 설계되었습니다. 로컬 메모리는높은 대역폭과 낮은 지연 시간으로 접근할 수 있습니다. 반면 다른 소켓의 메모리(원격 메모리, Remote Memory)에 접근하려면 소켓 간 인터커넥트(Intel UPI, AMD Infinity Fabric 등)를 경유해야 하므로 추가 지연이발생합니다. 어느 메모리에 접근하느냐에 따라 속도가 달라지므로 "비균일"이라는 이름이 붙었습니다.

UMA vs NUMA 비교 — 공유 버스 병목 (UMA) 과 분산 로컬 메모리 (NUMA) 의 차이

# 컴퓨터 과학

역사적 배경: NUMA는 1990년대 초 SGI(Silicon Graphics)의 대형 서버에서 처음 상용화되었습니다. Linux 커널은 2.5.x 개발 시리즈(2002년)부터 본격적인 NUMA 지원을 추가했으며, 오늘날 2개 이상의 CPU 소켓을가진 서버는 대부분 NUMA 아키텍처를 사용합니다. AMD EPYC는 단일 소켓에서도 여러 NUMA 노드를구성하는 NPS 기능으로 더 세밀한 메모리 로컬리티를 제공합니다.

2.2 NUMA 핵심 용어 정리

NUMA 문서와 커널 코드 전반에서 반복적으로 등장하는 핵심 용어를 정리합니다. 이 용어들을 먼저 익혀두면이후 섹션을 훨씬 쉽게 이해할 수 있습니다.

용어	설명	커널 표현 / 확인 명령
노드 (Node)	CPU 소켓과 그에 직접 연결된 로컬 메모리를 묶은 단위. NUMA 시스템의 기본 구성 요소	pg_data_t, NODE_DATA(nid)
로컬 메모리(Local Memory)	현재 실행 중인 CPU와 같은 노드에 있는 메모리. 접근 지연이 가장 낮고 대역폭이 높음	numa_node_id(), numastat의 local_node
원격 메모리(Remote Memory)	다른 노드에 있는 메모리. 인터커넥트를 경유하므로 로컬보다 1.5~3배 느림	numastat의 other_node, numa_miss
NUMA 거리(Distance)	노드 간 상대적 접근 비용. 자기 자신은 항상10, 값이 클수록 접근이 느림	numa_distance[][], SLIT 테이블, numactl -H
NUMA Ratio	원격 거리 / 로컬 거리 비율. 2.0 이상이면NUMA 최적화가 성능에 큰 영향을 미침	numactl --hardware의 node distances로 계산
NUMA Hit / Miss	로컬 노드에서 메모리 할당 성공(Hit) vs 원격 노드로 폴백(Miss). 낮은 Miss 비율이 좋음	/proc/vmstat의 numa_hit, numa_miss
NUMA Balancing	커널이 자동으로 페이지를 접근이 잦은 CPU 노드로 이동시키는 메커니즘. 장기 실행 프로세스의 로컬리티를 자동으로 개선	/proc/sys/kernel/numa_balancing
메모리 정책(Memory Policy)	메모리 할당 시 어떤 노드를 선택할지 규칙. DEFAULT, BIND, INTERLEAVE, PREFERRED 등	struct mempolicy, mbind(), numactl
로컬리티(Locality)	CPU와 접근하는 메모리가 같은 노드에 있어 빠르게 접근 가능한 상태. 좋은 로컬리티 = 높은 성능	NUMA Balancing이 자동으로 개선 시도
NUMA 친화성(Affinity)	특정 프로세스나 스레드를 특정 노드에서 실행하도록 바인딩하는 것	numactl --cpubind, set_mempolicy()

2.3 로컬 메모리와 원격 메모리의 성능 차이

NUMA의 핵심은 "어디서 메모리를 할당받았는가"가 성능에 직접 영향을 미친다는 점입니다. 같은 물리메모리라도 어느 CPU(소켓)에서 접근하느냐에 따라 지연 시간과 대역폭이 크게 달라집니다. 다음 예제는Node 0에서 실행 중인 프로세스가 로컬(Node 0)과 원격(Node 1) 메모리에 각각 접근할 때의 성능 차이를측정합니다. # 칩 및 프로세서

/* NUMA 로컬/원격 메모리 대역폭 측정 예제
 * 빌드: gcc -O2 -o numa_bench numa_bench.c -lnuma
 * 실행: numactl --cpubind=0 ./numa_bench
 */
#define _GNU_SOURCE
#include <numa.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#define BUF_SIZE  (256UL * 1024 * 1024)  /* 256 MB */
#define ITERS     10
static double bench_bandwidth(char *buf, size_t size)
{
    struct timespec t0, t1;
    volatile long sum = 0;
    memset(buf, 0, size);  /* 첫 접근으로 페이지 폴트 처리 */
    clock_gettime(CLOCK_MONOTONIC, &t0);
    for (int it = 0; it < ITERS; it++)
        for (size_t j = 0; j < size; j += 64)  /* 캐시 라인 단위 순차 읽기 */
            sum += *(volatile long *)(buf + j);
    clock_gettime(CLOCK_MONOTONIC, &t1);
    double elapsed = (t1.tv_sec - t0.tv_sec) +
                    (t1.tv_nsec - t0.tv_nsec) * 1e-9;
    return (double)(size * ITERS) / elapsed / (1024.0 * 1024 * 1024);
}
int main(void)
{
    if (numa_available() < 0 || numa_max_node() < 1) {
        fputs("NUMA 미지원 또는 단일 노드 시스템\n", stderr);
        return 1;
    }
    numa_run_on_node(0);  /* 현재 스레드를 Node 0에 고정 */
    /* Node 0 메모리 할당 → CPU 0 기준 로컬 접근 */
    char *local_buf  = numa_alloc_onnode(BUF_SIZE, 0);
    /* Node 1 메모리 할당 → CPU 0 기준 원격 접근 */
    char *remote_buf = numa_alloc_onnode(BUF_SIZE, 1);
    double local_bw  = bench_bandwidth(local_buf,  BUF_SIZE);
    double remote_bw = bench_bandwidth(remote_buf, BUF_SIZE);
    printf("로컬  메모리 대역폭: %.1f GB/s  (Node 0 → Node 0)\n", local_bw);
    printf("원격  메모리 대역폭: %.1f GB/s  (Node 0 → Node 1)\n", remote_bw);
    printf("성능 비율: %.2fx 차이\n", local_bw / remote_bw);
    numa_free(local_buf,  BUF_SIZE);
    numa_free(remote_buf, BUF_SIZE);
    return 0;
}
/* 일반적 출력 결과:
 * Intel 2소켓 Xeon (DDR4-3200):
 *   로컬  메모리 대역폭: 48.3 GB/s  (Node 0 → Node 0)
 *   원격  메모리 대역폭: 28.7 GB/s  (Node 0 → Node 1)
 *   성능 비율: 1.68x 차이
 *
 * AMD EPYC 2소켓 (NPS1, DDR5-4800):
 *   로컬  메모리 대역폭: 62.1 GB/s
 *   원격  메모리 대역폭: 38.4 GB/s
 *   성능 비율: 1.62x 차이
 */

왜 원격 메모리가 느린가: 원격 메모리 접근은 (1) 로컬 메모리 컨트롤러가 요청 수신 → (2) 소켓 간인터커넥트(UPI/IF)로 패킷(Packet) 전송 → (3) 원격 소켓의 메모리 컨트롤러에서 데이터 읽기 → (4) 인터커넥트로 응답 반환의 과정을 거칩니다. 각 단계에서 수십 나노초가 추가됩니다. 일반적으로 원격 접근은 로컬 접근보다 지연 시간 1.5~3배, 대역폭 50~70% 수준입니다. # 분산 및 클라우드 컴퓨팅

2.4 NUMA가 성능에 영향을 미치는 상황

모든 프로그램이 NUMA를 의식해야 하는 것은 아닙니다. 다음 표를 참고하여 NUMA 최적화가 실질적으로필요한지 판단하세요.

상황	NUMA 영향도	권장 조치
단일 소켓 서버 (1S)	없음	NUMA 고려 불필요
2소켓 서버, 소규모 단일 프로세스	낮음	기본 설정(Automatic NUMA Balancing)으로 충분
2소켓 서버, 메모리 대역폭 집약 워크로드(HPC, DB, ML 추론)	높음	numactl --cpubind=N --membind=N으로 노드 고정
4소켓 이상 대형 서버, 멀티 인스턴스DB/캐시	매우 높음	인스턴스당 노드 분리, mbind() 적극 적용
AMD EPYC NPS4 (소켓 내 4노드 분할)	높음	단일 소켓에서도 원격 메모리 발생, NUMA-aware 배치 필요
Redis, Memcached 등 단일 스레드 캐시 서버	중간	인스턴스를 노드별로 분리 운영(numactl --cpubind=N)
컨테이너/VM (vNUMA)	중간~높음	vNUMA 토폴로지를 호스트와 일치시켜 구성
Nginx, Apache 멀티 프로세스 웹 서버	낮음~중간	자동 NUMA Balancing으로 충분한 경우가 많음

NUMA 문제 증상 — 다음 증상이 보이면 NUMA 점검:
      •  numastat에서 numa_miss / (numa_hit + numa_miss) 비율이 5% 이상
      •   CPU 사용률은 낮은데 메모리 대기 시간(Latency)이 높은 상태 (sar -B 또는 perf stat)
  •  소켓 0은 메모리가 거의 없고 소켓 1은 여유가 많은 불균형 상태
  •  서비스 시작 후 한동안 성능이 낮다가 점점 올라가는 현상 (NUMA Balancing 적응 중)
  •  perf stat에서 mem_load_retired.remote_dram 이벤트 비율이 높음 (Intel)

2.5 내 시스템 NUMA 현황 첫 진단

NUMA 시스템을 처음 다룬다면 다음 순서로 진단을 시작하세요. 각 명령의 출력을 어떻게 해석해야 하는지도함께 설명합니다. # 운영체제

# ① NUMA 시스템인지 먼저 확인
$ numactl --hardware
available: 2 nodes (0-1)   # 2개 이상이면 NUMA 시스템
node 0 cpus: 0 1 2 3 4 5 6 7 # Node 0에 속한 CPU 번호
node 0 size: 65536 MB         # Node 0의 물리 메모리 용량
node 0 free: 48230 MB         # Node 0의 현재 여유 메모리
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 65536 MB
node 1 free: 51200 MB
node distances:               # NUMA 거리 매트릭스
node   0   1
  0:  10  21                # 10=로컬, 21=Node 1로의 원격 거리
  1:  21  10                # NUMA Ratio = 21/10 = 2.1 → 최적화 강력 권장
# ② 현재 NUMA Miss 통계 확인 (miss 비율 5% 이상이면 문제)
$ numastat
                           node0           node1
numa_hit               142857391       98234567   # 로컬 할당 성공 횟수
numa_miss                1234567        2345678   # 원격 폴백 횟수 (낮을수록 좋음)
numa_foreign             2345678        1234567   # 이 노드가 다른 노드의 miss를 수용
local_node             139400824       95888889
other_node               4690134        4690356   # 원격 할당 횟수
# ③ 특정 프로세스의 노드별 메모리 분포 확인
$ numastat -p $(pgrep -x mysqld)
Per-node process memory usage (MB):
         Node 0         Node 1          Total
Heap       512.00       256.00        768.00   # 이상적으로는 한 노드에 집중
Total      850.48       320.23       1170.71   # 분산이 크면 --membind 사용 고려
# ④ NUMA Balancing 상태 확인
$ cat /proc/sys/kernel/numa_balancing
1   # 1=자동 밸런싱 활성화 (대부분의 경우 권장)
    # 지연 민감 워크로드는 0으로 비활성화 후 수동 배치
# ⑤ miss 비율 계산 (5% 이상이면 NUMA 최적화 필요)
$ numastat | awk '/numa_hit/{hit=$2+$3} /numa_miss/{miss=$2+$3}
  END{printf "Miss 비율: %.1f%%\n", miss*100/(hit+miss)}'
Miss 비율: 1.7%   # 5% 미만이면 양호한 상태
# ⑥ CPU가 어느 NUMA 노드에 속하는지 확인
$ cat /sys/devices/system/node/node0/cpulist
0-7   # Node 0에 CPU 0-7이 속함
$ cat /sys/devices/system/cpu/cpu3/topology/physical_package_id
0     # CPU 3은 소켓(패키지) 0 = Node 0

NUMA Ratio 해석: node distances의 원격 거리를 10으로 나누면 NUMA Ratio가 나옵니다.
   •  거리 11~15 (Ratio 1.1~1.5): 영향이 적음. 자동 밸런싱으로 충분
   •  거리 21 (Ratio 2.1): 원격이 로컬보다 약 2배 느림. NUMA-aware 배치 강력 권장
   •  거리 31 이상 (Ratio 3.1+): 2홉 이상 원격. 성능 차이 매우 큼. 반드시 노드 격리 필요

3. NUMA 하드웨어 토폴로지

NUMA(Non-Uniform Memory Access) 시스템에서 각 CPU 소켓은 자신에게 직접 연결된 로컬 메모리를가지며, 다른 소켓의 메모리에 접근할 때는 인터커넥트(QPI, UPI, Infinity Fabric 등)를 경유합니다. 이로 인해메모리 접근 지연 시간(latency)과 대역폭(bandwidth)이 위치에 따라 달라집니다. # 컴퓨터 메모리

2- 소켓 NUMA 토폴로지 — 로컬 / 리모트 메모리 접근 지연 시간 차이

4소켓 이상의 대규모 서버에서는 인터커넥트가 멀티홉(Multi-hop)으로 구성되어 NUMA 거리 편차가 더커집니다. 직접 연결된 노드(1홉)과 중간 노드를 경유하는 노드(2홉)의 지연 시간 차이가 크므로, 애플리케이션 배치 전략이 2소켓보다 훨씬 중요합니다. # 데이터 관리

4- 소켓 NUMA 토폴로지 — 직접 연결 (1 홉 , 거리 21) 과 중간 경유 (2 홉 , 거리 31) 의 비대칭 거리

# 분산 및 클라우드 컴퓨팅

3.1 NUMA Ratio와 영향

시스템 유형	인터커넥트	로컬 지연 (일반적 범위)	리모트 지연 (일반적 범위)	NUMA Ratio
Intel 2S (Xeon Scalable)	UPI 2.0/3.0	~80ns	~130-150ns	1.6-1.9x
Intel 4S/8S	UPI (멀티홉)	~80ns	~170-300ns	2.1-3.7x
AMD EPYC (2S)	Infinity Fabric	~90ns	~140-160ns	1.5-1.8x
AMD EPYC (NPS4)	IF (소켓 내)	~85ns	~110-130ns	1.3-1.5x
ARM64 서버	CCIX/CXL	~100ns	~200-350ns	2.0-3.5x
CXL 메모리 확장	CXL 2.0	~80ns	~170-250ns	2.1-3.1x

# NUMA 토폴로지와 거리 매트릭스 확인
$ numactl --hardware | grep -A10 "node distances"
node distances:
node   0   1
  0:  10  21
  1:  21  10
# NUMA Ratio 계산: 원격 거리 / 로컬 거리 = 21 / 10 = 2.1
# 2.0 이상이면 NUMA 최적화 필수, 1.5 이하면 영향 적음
# 커널의 NUMA 거리 정보 (sysfs)
$ cat /sys/devices/system/node/node0/distance
10 21
# 커널 부팅 시 NUMA 탐색 로그
$ dmesg | grep -i numa
[    0.000000] SRAT: Node 0 PXM 0 [mem 0x00000000-0x7fffffff]
[    0.000000] SRAT: Node 1 PXM 1 [mem 0x80000000-0xffffffff]
[    0.000000] NUMA: Node 0 [mem 0x00000000-0x7fffffff] + ...
[    0.000000] NUMA: Initmem setup node 0 [mem 0x00000000-...]

AMD NPS (Nodes Per Socket): AMD EPYC 프로세서는 NPS 설정으로 단일 소켓 내부를 여러 NUMA 노드로 분할합니다. NPS1(1노드), NPS2(2노드), NPS4(4노드) 모드를 지원합니다. NPS4에서는 소켓 당4개의 CCD 그룹이 각각 독립 NUMA 노드가 되어, 로컬 메모리 접근 범위는 줄지만 지연 시간 편차가감소합니다.

# 칩 및 프로세서

3.2 AMD EPYC NPS(Nodes Per Socket) 토폴로지

AMD EPYC 프로세서(Processor)는 CCD(Core Complex Die) 칩렛 아키텍처를 사용합니다. BIOS에서 NPS 설정을 변경하면 단일 소켓 내부의 NUMA 노드 수를 조절할 수 있습니다. NPS 값이 높을수록 로컬 메모리범위는 줄어들지만 접근 지연 편차가 감소합니다.

AMD EPYC NPS 모드 — NPS1( 전체 통합 ), NPS2(2 분할 ), NPS4(CCD 별 독립 노드 ) 의 메모리 -CPU 매핑 (Mapping)

NPS 모드	소켓당 노드 수	노드당 메모리 채널	특징	적합한 워크로드
NPS1	1	전체 (8 또는12)	최대 대역폭, 높은 지연 편차	단일 대형 프로세스 (JVM, 단일DB 인스턴스)
NPS2	2	절반 (4 또는6)	대역폭/지역성 균형	범용 서버, 가상화(Virtualization)
NPS4	4	1/4 (2 또는3)	최소 지연 편차, 좁은 로컬 범위	HPC, 지연 민감 워크로드

3.3 Intel SNC(Sub-NUMA Clustering)

Intel Xeon Scalable 프로세서도 SNC(Sub-NUMA Clustering) 기능으로 소켓 내부를 여러 NUMA 노드로분할합니다. SNC2는 소켓을 2개, SNC4(4세대 이상)는 4개의 NUMA 노드로 분할합니다. AMD NPS와 개념은유사하지만, Intel은 LLC(Last Level Cache) 슬라이스를 기준으로 분할합니다. # 컴퓨터 하드웨어

Intel SNC2 — 단일 소켓 내 코어 /LLC/ 메모리 컨트롤러를 2 개 NUMA 도메인으로 분할

NPS/SNC 변경 주의: NPS나 SNC 설정을 변경하면 시스템의 NUMA 토폴로지가 바뀌므로, numactl 바인딩스크립트, cgroup cpuset.mems 설정, IRQ 친화성(Affinity) 규칙을 모두 재검토해야 합니다. 변경 전후에 numactl --hardware로 토폴로지를 확인하세요.

CPU 토폴로지: AMD CCX/CCD/IOD 칩렛 구조, Intel Tile/Hybrid 아키텍처, ARM DynamIQ, Infinity Fabric, 스케줄링 도메인(Scheduling Domain) 계층에 대한 종합적인 내용은 CPU 토폴로지 페이지를 참조하세요.

# 컴퓨터 메모리

4. ACPI를 통한 NUMA 토폴로지 검색

커널은 부팅 시 ACPI 테이블을 파싱하여 NUMA 토폴로지를 구성합니다. 핵심 테이블은 SRAT(Static Resource Affinity Table)와 SLIT(System Locality Information Table)입니다.

4.1 SRAT (Static Resource Affinity Table)

/*
 * SRAT는 CPU와 메모리가 어떤 NUMA 노드에 속하는지 정의합니다.
 *
 * SRAT 하위 구조:
 * - Processor Local APIC Affinity: CPU(APIC ID) → Node 매핑
 * - Memory Affinity: 메모리 범위 → Node 매핑
 * - Processor Local x2APIC Affinity: x2APIC CPU → Node 매핑
 * - GICC Affinity: ARM64 CPU → Node 매핑
 * - Generic Initiator Affinity: CXL 장치 등 → Node 매핑
 */
/* arch/x86/kernel/acpi/srat.c */
static int __init
acpi_parse_processor_affinity(union acpi_subtable_headers *header,
                              const unsigned long end)
{
    struct acpi_srat_cpu_affinity *p =
        (struct acpi_srat_cpu_affinity *)header;
    int pxm = p->proximity_domain_lo |
              (p->proximity_domain_hi[0] << 8) |
              (p->proximity_domain_hi[1] << 16) |
              (p->proximity_domain_hi[2] << 24);
    /* proximity domain → NUMA node 매핑 등록 */
    set_apicid_to_node(p->apic_id, pxm_to_node(pxm));
    return 0;
}
static int __init
acpi_parse_memory_affinity(union acpi_subtable_headers *header,
                           const unsigned long end)
{
    struct acpi_srat_mem_affinity *ma =
        (struct acpi_srat_mem_affinity *)header;
    u64 start = ma->base_address;
    u64 length = ma->length;
    int node = pxm_to_node(ma->proximity_domain);
    /* 메모리 범위를 노드에 등록 */
    numa_add_memblk(node, start, start + length);
    return 0;
}

리눅스 커널의 ACPI SRAT(System Resource Affinity Table) 파싱 루틴 일부입니다.

ACPI 표 중 하나인 SRAT는 NUMA(Non-Uniform Memory Access) 아키텍처에서 물리적 리소스(CPU Core, 메모리 주소 영역, CXL 장치 등)가 어느 NUMA 노드(Proximity Domain)에 속해 있는지 리눅스 커널에 알려주는 핵심 역할을 합니다.

각 함수가 리눅스 부팅 과정에서 어떻게 작동하는지 핵심을 간단히 짚어가시죠.

(1) acpi_parse_processor_affinity

CPU(APIC ID)를 NUMA 노드에 매핑

동작 방식:
1. 전달받은 SRAT 서브테이블 헤더를 acpi_srat_cpu_affinity 구조체로 형변환합니다.
2. 하위 8비트(proximity_domain_lo)와 상위 24비트(proximity_domain_hi)를 비트 시프트 연산으로 합쳐 32비트 Proximity Domain(PXM) ID를 복원합니다.
3. pxm_to_node(pxm)를 통해 ACPI의 PXM ID를 리눅스 커널의 internal NUMA Node ID로 변환합니다.
4. set_apicid_to_node(...)를 호출하여 특정 CPU의 APIC ID가 어떤 NUMA 노드에 속하는지 커널 테이블에 등록합니다.

(2) acpi_parse_memory_affinity

물리 메모리 구간(Base Address ~ Length)을 NUMA 노드에 매핑

동작 방식:
1. 헤더를 acpi_srat_mem_affinity 구조체로 형변환합니다.
2. 해당 메모리 영역의 시작 주소(base_address)와 크기(length)를 추출합니다.
3. PXM을 NUMA Node ID로 변환합니다.
4. numa_add_memblk(node, start, start + length)를 호출해 특정 주소 범위의 메모리가 어느 NUMA 노드 메모리 블록에 해당하는지 커널에 추가합니다.

요약 및 핵심 포인트

부팅 시점: 이 함수들은 초기화 함수(__init)로, 커널이 스케줄러와 메모리 관리자(Zone/Buddy Allocator)를 구성하기 직전에 실행됩니다.
성능 임팩트: 커널은 이 정보를 바탕으로 "CPU가 자신과 가장 가까운(LOCAL) 메모리에 우선적으로 물리 메모리를 할당"하도록 스케줄링 및 메모리 정책을 수립합니다. (NUMA Remote Access로 인한 병목 현상 방지)

4.2 SLIT (System Locality Information Table)

/*
 * SLIT는 노드 간 상대적 거리를 N×N 매트릭스로 정의합니다.
 * 거리 10 = 자기 자신 (로컬), 값이 클수록 먼 노드
 *
 * 예시: 4-노드 시스템 SLIT 매트릭스
 *       Node0  Node1  Node2  Node3
 * Node0:  10     21     31     41
 * Node1:  21     10     21     31
 * Node2:  31     21     10     21
 * Node3:  41     31     21     10
 */
/* drivers/acpi/numa/srat.c */
void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
{
    int i, j;
    for (i = 0; i < slit->locality_count; i++)
        for (j = 0; j < slit->locality_count; j++)
            numa_set_distance(
                pxm_to_node(i),
                pxm_to_node(j),
                slit->entry[i * slit->locality_count + j]);
}

4.3 HMAT (Heterogeneous Memory Attribute Table)

HMAT는 ACPI 6.2에서 도입된 테이블로, 각 메모리 초기자(Initiator, 예: CPU)와 메모리 대상(Target, 예: DRAM, CXL) 간의 지연 시간(Latency)과 대역폭(Bandwidth)을 구체적인 수치로 제공합니다. SLIT가 상대적거리만 제공하는 반면, HMAT는 절대적인 성능 특성을 전달합니다. # 분산 및 클라우드 컴퓨팅

/*
 * HMAT 주요 구조:
 *
 * 1. Memory Proximity Domain Attributes
 *    - 각 노드의 메모리 특성 (읽기/쓰기 지연, 대역폭)
 *
 * 2. System Locality Latency and Bandwidth Information
 *    - 이니시에이터 → 타겟 간 접근 성능 매트릭스
 *    - 유형: Access, Read, Write 각각 별도
 *
 * 3. Memory Side Cache Information
 *    - CXL 장치 등의 메모리 사이드 캐시 정보
 *
 * 커널 파싱: drivers/acpi/numa/hmat.c
 * → hmat_parse_proximity_domain()
 * → hmat_parse_locality()
 * → hmat_parse_cache()
 */
/* drivers/acpi/numa/hmat.c — HMAT 지연/대역폭 파싱 */
static int __init hmat_parse_locality(
    union acpi_subtable_headers *header,
    const unsigned long end)
{
    struct acpi_hmat_locality *loc =
        (struct acpi_hmat_locality *)header;
    /* data_type: 0=Access, 1=Read, 2=Write */
    /* min_transfer_size, 대상 노드 수, 이니시에이터 수 */
    for (initiator ...) {
        for (target ...) {
            u16 value = entries[initiator * targets + target];
            /* value는 나노초(latency) 또는 MB/s(bandwidth) */
            hmat_update_target_access(target, initiator,
                                     loc->data_type, value);
        }
    }
    return 0;
}

# HMAT 정보 확인 (sysfs)
# 각 노드의 접근 성능 속성
$ ls /sys/devices/system/node/node0/access0/initiators/
read_bandwidth  read_latency  write_bandwidth  write_latency
# Node 0에서 자기 자신(DRAM) 접근
$ cat /sys/devices/system/node/node0/access0/initiators/read_latency
80    # 80ns
$ cat /sys/devices/system/node/node0/access0/initiators/read_bandwidth
51200 # 51.2 GB/s
# CXL 노드 (Node 2)의 접근 성능
$ cat /sys/devices/system/node/node2/access0/initiators/read_latency
170   # 170ns (CXL 경유)
$ cat /sys/devices/system/node/node2/access0/initiators/read_bandwidth
32000 # 32 GB/s
# dmesg에서 HMAT 파싱 결과 확인
$ dmesg | grep -i hmat
ACPI: HMAT: Memory Proximity Domain Attributes: PXM=0 Init=0
ACPI: HMAT: Locality: Flags=0 Type=Access Initiator Domains=2 Target Domains=3
ACPI: HMAT: Initiator=0 Target=0 Read Latency=80ns
ACPI: HMAT: Initiator=0 Target=2 Read Latency=170ns

HMAT와 메모리 티어링: 커널의 메모리 티어링 프레임워크(CONFIG_MEMORY_TIER)는 HMAT의 지연/대역폭정보를 기반으로 메모리 노드를 자동으로 티어(빠른/느린)로 분류합니다. HMAT가 없는시스템에서는 /sys/devices/system/node/nodeN/memtier를 수동으로 설정해야 합니다.

# 칩 및 프로세서

4.3 토폴로지 확인 명령

# NUMA 노드 목록
$ ls /sys/devices/system/node/
node0  node1
# 노드별 CPU 매핑
$ cat /sys/devices/system/node/node0/cpulist
0-7,16-23
$ cat /sys/devices/system/node/node1/cpulist
8-15,24-31
# 노드 간 거리 매트릭스
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 65366 MB
node 0 free: 48230 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 65536 MB
node 1 free: 51200 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10
# SRAT 정보 (dmesg)
$ dmesg | grep -i srat
ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0fffffff]
ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff]
ACPI: SRAT: Node 1 PXM 1 [mem 0x1000000000-0x1fffffffff]
# lstopo (hwloc)로 시각적 토폴로지 확인
$ lstopo --of txt
Machine (128GB total)
  NUMANode L#0 (P#0 64GB)
    Package L#0
      L3 L#0 (30MB)
        L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0
          PU L#0 (P#0)
          PU L#1 (P#16)
        ...
  NUMANode L#1 (P#1 64GB)
    ...

앞서 보셨던 ACPI SRAT 테이블을 파싱한 후, 리눅스 커널이 실제로 구성한 NUMA 토폴로지의 현황을 보여주는 셸 실행 결과입니다.

가장 중요한 포인트들을 정리해 드릴게요.

(1) CPU 번호 할당 규칙 (SMT / 하이퍼스레딩)

node 0 cpus: 0-7, 16-23
node 1 cpus: 8-15, 24-31

CPU ID가 연속적이지 않고 중간에 징검다리처럼 꺾이는 이유는 SMT(Hyper-Threading) 때문입니다.
Node 0의 물리 코어에는 CPU 0~7이 할당되고, 해당 코어들의 논리 스레드(Sibling Thread)에는 CPU 16~23이 매핑되어 있습니다.
lstopo 명령어 결과를 보면 Core L#0 아래에 PU L#0 (P#0)과 PU L#1 (P#16)이 한 쌍으로 들어가 있는 것을 볼 수 있습니다.

(2) SLIT (System Locality Information Table) 거리 매트릭스

node distances:
node   0   1
  0:  10  21
  1:  21  10

10 (Local Access): 기준값 10은 자신 노드의 메모리에 접근할 때의 레이턴시(가장 빠른 상태)입니다.
21 (Remote Access): CPU가 Interconnect(Intel UPI 또는 AMD Infinity Fabric)를 넘어 타 노드 메모리에 접근할 때는 약 2.1배의 레이턴시 손실이 발생함을 나타냅니다.

(3) SRAT 파싱 결과 (dmesg)

ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x0fffffff]
ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff]
ACPI: SRAT: Node 1 PXM 1 [mem 0x1000000000-0x1fffffffff]

이전에 본 acpi_parse_memory_affinity() 함수가 정상 실행되어 ACPI Proximity Domain(PXM) 0과 1의 물리 주소 범위가 노드 0과 1에 정확히 추가되었음을 보여줍니다.
Node 0 주소 불연속: Node 0의 메모리가 중간에 비어 보이는 이유는 4GB 미만 구간(0x00000000~0x0fffffff)에 레거시 PCI/MMIO 장치 전용 예약 공간(PCI Hole)이 존재하여 메모리 mapping이 둘로 쪼개졌기 때문입니다.

실무 팁 (성능 최적화)

이러한 NUMA 구조를 파악했다면, 데이터베이스나 고성능 애플리케이션 실행 시 다음과 같이 메모리와 CPU를 바인딩하여 Remote Access(거리 21) 발생을 차단할 수 있습니다.

# Node 0의 CPU와 메모리만 사용하여 프로세스 실행
$ numactl --cpunodebind=0 --membind=0 ./my_high_perf_app

5. 커널 자료구조: pglist_data

각 NUMA 노드는 struct pglist_data (별칭 pg_data_t)로 표현됩니다. 이 구조체는 노드의 메모리 존, 페이지프레임(Page Frame), 통계 정보를 모두 관리합니다.

# 컴퓨터 과학

/* include/linux/mmzone.h (주요 필드 발췌) */
typedef struct pglist_data {
    /* ---- 존 정보 ---- */
    struct zone node_zones[MAX_NR_ZONES];    /* 노드 내 존 배열 */
    struct zonelist node_zonelists[MAX_ZONELISTS]; /* 할당 폴백 순서 */
    int nr_zones;                             /* 활성 존 수 */
    /* ---- 페이지 프레임 ---- */
    struct page *node_mem_map;                 /* 노드의 struct page 배열 */
    unsigned long node_start_pfn;              /* 시작 페이지 프레임 번호 */
    unsigned long node_present_pages;           /* 실제 존재하는 페이지 수 */
    unsigned long node_spanned_pages;           /* 시작~끝 범위 (hole 포함) */
    int node_id;                               /* 이 노드의 번호 */
    /* ---- 페이지 회수 (reclaim) ---- */
    wait_queue_head_t kswapd_wait;             /* kswapd 대기 큐 */
    wait_queue_head_t pfmemalloc_wait;
    struct task_struct *kswapd;                /* 이 노드의 kswapd 스레드 */
    int kswapd_order;
    enum zone_type kswapd_highest_zoneidx;
    /* ---- LRU 리스트 (페이지 에이징) ---- */
    struct lruvec __lruvec;                    /* 노드 단위 LRU 벡터 */
    /* ---- 통계 ---- */
    unsigned long totalreserve_pages;
    struct per_cpu_nodestat __percpu *per_cpu_nodestats;
    /* ---- Compaction ---- */
    unsigned long compact_cached_free_pfn;
    unsigned long compact_cached_migrate_pfn[ASYNC_AND_SYNC];
    /* ---- NUMA Balancing ---- */
    spinlock_t numabalancing_migrate_lock;
    unsigned long numabalancing_migrate_nr_pages;
    unsigned long numabalancing_migrate_next_window;
} pg_data_t;
/* 전역 노드 배열 */
extern struct pglist_data *node_data[];
#define NODE_DATA(nid)  (node_data[nid])

pglist_data(Node 0) — 존 배열 , zonelist 폴백 순서 , zone 구조체의 주요 필드

# 운영체제

5.1 Zonelist — 할당 폴백 순서

/* * 메모리 할당 시 존리스트(zonelist)를 따라 폴백합니다. * * Node 0의 zonelist[ZONELIST_FALLBACK]: * Node0:ZONE_NORMAL → Node0:ZONE_DMA32 → Node0:ZONE_DMA * → Node1:ZONE_NORMAL → Node1:ZONE_DMA32 → Node1:ZONE_DMA * * 순서: 로컬 노드 우선 → 거리가 가까운 노드 순 * SLIT 거리기반으로 정렬됨 */struct zonelist { struct zoneref _zonerefs[MAX_ZONES_PER_ZONELIST + 1];};struct zoneref { struct zone *zone; /* 존 포인터 */ int zone_idx; /* 존 인덱스 */};/* zonelist 탐색 매크로*/for_each_zone_zonelist(zone, z, zonelist, highest_zoneidx) { /* 로컬 노드부터 리모트 노드까지 순서대로 시도*/ page = rmqueue(zone, order, gfp_mask); if (page) return page;}

5.2 노드 통계 확인

# 노드별 메모리 통계 (/sys/devices/system/node/node*/meminfo)
$ cat /sys/devices/system/node/node0/meminfo
Node 0 MemTotal:       65536000 kB
Node 0 MemFree:        48230000 kB
Node 0 MemUsed:        17306000 kB
Node 0 Active:         8120000 kB
Node 0 Inactive:       6450000 kB
Node 0 AnonPages:      5230000 kB
Node 0 FilePages:      9340000 kB
Node 0 Slab:           1530000 kB
Node 0 SReclaimable:   1200000 kB
...
# 노드별 존 정보
$ cat /proc/zoneinfo | grep -A3 "Node 0"
Node 0, zone   Normal
  pages free     12057500
        min      16384
        low      20480
# numastat — 노드별 NUMA 적중/미스 통계
$ numastat
                           node0           node1
numa_hit               142857391       98234567
numa_miss                1234567        2345678
numa_foreign             2345678        1234567
interleave_hit           3456789        3456789
local_node             139400824       95888889
other_node               4690134        4690356

6. NUMA 메모리 정책

Linux 커널은 프로세스와 메모리 영역별로 NUMA 메모리 할당 정책을 지정할 수 있습니다. 이는 set_mempolicy(), mbind() 시스템 콜(System Call)과 numactl 도구로 제어합니다.

# 소프트웨어

메모리 정책이란 (기초 개념): NUMA 시스템에서 "어느 노드의 메모리에서 할당할지"를 결정하는규칙입니다. 예를 들어 numactl --membind=0 ./app 을 실행하면 app이 사용하는 메모리는 반드시 Node 0에서만할당됩니다. 정책을 지정하지 않으면 커널은 현재 CPU와 같은 노드(로컬)에서 우선 할당을 시도합니다. 네가지 핵심 정책:
   •  DEFAULT: 상위 정책(태스크 → 시스템)으로 폴백. mbind()로 지정한 VMA 정책 해제 시 사용
   •  BIND: 지정 노드에서만 강제 할당. 해당 노드 메모리 부족 시 OOM 발생. 완벽한 메모리 격리 목적
   •  PREFERRED: 선호 노드를 지정하되, 부족하면 다른 노드로 폴백. 소프트 바인딩
   •  INTERLEAVE: 지정 노드들에 라운드-로빈으로 분산 할당. 전체 대역폭 극대화(대형 해시 테이블 등)

6.1 정책 유형

정책	상수	동작	용도
Default	MPOL_DEFAULT	명시 정책을 제거하고 다음으로 구체적인 범위로 폴백	task/VMA 정책 해제, system default 복귀
Bind	MPOL_BIND	지정된 노드 집합에서만 할당 (실패 시 OOM)	메모리 격리(Isolation),전용 노드
Preferred	MPOL_PREFERRED	선호 노드에서 우선 할당, 실패 시 다른 노드 폴백	소프트 바인딩
Preferred Many	MPOL_PREFERRED_MANY	지정 nodemask 내에서 우선 만족시키고 부족하면 다른 노드 폴백	유연한 선호(v5.15+)
Interleave	MPOL_INTERLEAVE	익명/공유 메모리는 page offset, page cache는 task 카운터 기준 분산	대역폭 극대화, 해시 테이블(Hash Table)
Local	MPOL_LOCAL	폴백이 아니라 명시적으로local allocation을 선택	MPOL_DEFAULT와 구분되는 명시적 로컬 할당
Weighted Interleave	MPOL_WEIGHTED_INTERLEAVE	MPOL_INTERLEAVE와 같은 경로에서 가중치 비율만 다르게 적용	CXL 이종 메모리, 비대칭 대역폭 환경 (v6.9+)

6.2 정책 범위와 재바인딩

mempolicy는 단일 전역 설정이 아닙니다. 커널은 정책 범위(Policy Scope)를 system default, task policy, VMA policy, shared policy로 나누어 해석하며, 어떤 범위가 실제로 적용되는지는 매핑 유형과 cpuset 제약에 따라달라집니다. 특히 regular file의 MAP_SHARED page cache는 VMA 정책을 직접 따르지 않는다는 점을명시적으로 이해해야 합니다.

# 컴퓨터 메모리

항목	핵심 의미	실전 주의점
MPOL_F_STATIC_NODES	cpuset 허용 노드가 바뀌어도 사용자nodemask를 상대 재해석하지 않습니다.	허용 노드와 교집합이 비면 정책이 사실상 무력화되고 default/local 폴백처럼 보일 수 있습니다.
MPOL_F_RELATIVE_NODES	사용자 nodemask를 현재 cpuset에 대한 상대 위치로 해석합니다.	컨테이너(Container)나 cpuset이 자주 바뀌는 환경에서 더 예측 가능하지만, 실제 물리 노드 번호와 1:1 대응된다고 보면 안 됩니다.
MPOL_F_NUMA_BALANCING	MPOL_BIND와 함께NUMA balancing을 허용하는 플래그입니다.	모든 mode에 붙는 범용 플래그가 아닙니다. 잘못 조합하면 EINVAL이 납니다.
home node	기존 VMA 정책 범위에 대해 할당 시작점을 더 가까운 노드로 조정합니다.	set_mempolicy_home_node()는 새 정책 생성이 아니라 기존 VMA policy 범위의 home node만 갱신합니다.

6.3 시스템 콜

#include <numaif.h>

/* 프로세스 전체 NUMA 정책 설정 */
long set_mempolicy(
    int mode,                /* MPOL_DEFAULT, MPOL_BIND, ... */
    const unsigned long *nodemask,  /* 대상 노드 비트마스크 */
    unsigned long maxnode   /* nodemask 비트 수 */
);

/* 특정 메모리 영역의 NUMA 정책 설정 */
long mbind(
    void *addr,              /* 시작 주소 (페이지 정렬) */
    unsigned long len,       /* 길이 */
    int mode,                /* MPOL_BIND, MPOL_INTERLEAVE, ... */
    const unsigned long *nodemask,
    unsigned long maxnode,
    unsigned int flags       /* MPOL_MF_MOVE, MPOL_MF_STRICT, ... */
);

/* 현재 task policy, 특정 주소의 policy, 또는 노드 위치 조회 */
long get_mempolicy(
    int *policy,
    unsigned long *nodemask,
    unsigned long maxnode,
    void *addr,
    unsigned long flags      /* MPOL_F_NODE, MPOL_F_ADDR */
);

/* 페이지를 다른 노드로 마이그레이션 */
long migrate_pages(
    pid_t pid,
    unsigned long maxnode,
    const unsigned long *old_nodes,  /* 원본 노드 */
    const unsigned long *new_nodes   /* 대상 노드 */
);

/* 개별 페이지 단위 마이그레이션 */
long move_pages(
    pid_t pid,
    unsigned long count,
    void **pages,             /* 페이지 주소 배열 */
    const int *nodes,        /* 대상 노드 배열 (NULL이면 조회) */
    int *status,              /* 결과/현재 노드 */
    int flags
);

API 역할 구분: set_mempolicy()는 task default policy를 바꾸고, mbind()는 주소 범위의 VMA/shared policy를설정합니다. get_mempolicy()는 현재 task policy를 복원 가능한 형태로 읽거나, 플래그 조합에 따라 특정 주소의policy 또는 현재 노드 위치를 조회하는 API입니다.

# 분산 및 클라우드 컴퓨팅

6.4 numactl 사용

# 특정 노드에서만 메모리 할당 (bind)
$ numactl --membind=0 ./my_application

# 특정 CPU에서 실행 + 해당 노드의 메모리 사용
$ numactl --cpunodebind=0 --membind=0 ./my_application

# 인터리브 모드 (모든 노드에 분산)
$ numactl --interleave=all ./hash_table_server

# 선호 노드 지정 (폴백 허용)
$ numactl --preferred=1 ./my_application

# 현재 실행 중인 프로세스의 NUMA 매핑 확인
$ numastat -p <pid>
Per-node process memory usage (in MBs) for PID <pid>
                          Node 0      Node 1       Total
                 --------- --------- -----------
Huge                  0.00      0.00        0.00
Heap                256.50     12.30      268.80
Stack                 0.12      0.00        0.12
Private            1024.00     48.00     1072.00
...

# 프로세스의 NUMA 메모리 맵 (/proc/PID/numa_maps)
$ cat /proc/self/numa_maps
00400000 default file=/usr/bin/cat mapped=10 N0=10
7f8a1000 default anon=3 dirty=3 N0=2 N1=1
7ffd2000 default stack anon=2 dirty=2 N0=2

6.5 커널 내부 NUMA 할당 API

/* NUMA-aware 커널 메모리 할당 */

/* 특정 노드에서 페이지 할당 */
struct page *alloc_pages_node(int nid, gfp_t gfp, unsigned int order);

/* 현재 CPU의 로컬 노드에서 할당 */
struct page *alloc_pages(gfp_t gfp, unsigned int order);

/* 특정 노드에서 slab 할당 */
void *kmalloc_node(size_t size, gfp_t flags, int node);
void *kzalloc_node(size_t size, gfp_t flags, int node);
void *kvmalloc_node(size_t size, gfp_t flags, int node);

/* kmem_cache에서 특정 노드 할당 */
void *kmem_cache_alloc_node(struct kmem_cache *s, gfp_t flags, int node);

/* GFP 플래그로 NUMA 제어 */
__GFP_THISNODE   /* 지정된 노드에서만 할당 (폴백 금지) */

/* 현재 CPU의 NUMA 노드 번호 */
int nid = numa_node_id();         /* 현재 CPU의 노드 */
int nid = cpu_to_node(cpu);       /* 특정 CPU의 노드 */
int nid = page_to_nid(page);      /* 페이지가 속한 노드 */

/* 디바이스의 NUMA 노드 (PCIe 장치 등) */
int nid = dev_to_node(dev);        /* 장치에 가장 가까운 노드 */

/* 예시: NIC의 로컬 노드에 sk_buff 할당 */
int nid = dev_to_node(&netdev->dev);
skb = __alloc_skb(size, GFP_ATOMIC, 0, nid);

7. Automatic NUMA Balancing

Automatic NUMA Balancing은 커널이 자동으로 프로세스의 메모리를 적절한 NUMA 노드로마이그레이션하는 메커니즘입니다. 사용자 공간(User Space)의 개입 없이 NUMA 지역성을 최적화합니다. # 운영체제

왜 자동 밸런싱이 필요한가: NUMA 시스템에서 프로세스를 처음 시작하면 메모리가 최적이 아닌 노드에할당될 수 있습니다. 예를 들어 Node 0에서 시작된 프로세스의 스레드가 나중에 Node 1의 CPU에서 실행되면자신의 데이터에 원격 접근을 반복하게 됩니다. Automatic NUMA Balancing은 이 불일치를감지하여 페이지를 자주 접근하는 CPU의 노드로 자동 이동시킵니다. 단, 이 과정에서 짧은 성능 저하(NUMA 페이지 폴트(Page Fault))가 발생하므로, 지연 시간이 극도로 민감한 워크로드에서는 비활성화(echo 0 > /proc/sys/kernel/numa_balancing) 후 수동 배치(numactl)가 더 적합합니다.

7.1 동작 원리

Automatic NUMA Balancing은 4단계 파이프라인(Pipeline)으로 동작합니다. 스캔 → 폴트 → 판단 → 마이그레이션 순서로, 커널이 자동으로 페이지와 태스크(Task)의 NUMA 배치를 최적화합니다.

Automatic NUMA Balancing — 스캔 → 폴트 → 판단 → 마이그레이션 4 단계와 두 가지 최적화 경로

# 분산 및 클라우드 컴퓨팅

7.2 NUMA Hinting Fault

/* mm/memory.c — NUMA hinting fault 처리 */
static vm_fault_t do_numa_page(struct vm_fault *vmf)
{
    struct vm_area_struct *vma = vmf->vma;
    struct page *page;
    int page_nid, target_nid, last_cpupid;
    bool migrated;

	/* 현재 PTE 복원 (PROT_NONE → 원래 권한) */
    pte = pte_modify(old_pte, vma->vm_page_prot);

	page = vm_normal_page(vma, vmf->address, pte);
    page_nid = page_to_nid(page);        /* 페이지의 현재 노드 */
    target_nid = numa_migrate_prep(page, vma, vmf->address,
                                    page_nid, &flags);

	if (target_nid == NUMA_NO_NODE) {
        /* 마이그레이션 불필요: 이미 최적 위치 */
        put_page(page);
        goto out;
    }

	/* 페이지를 target_nid로 마이그레이션 시도 */
    migrated = migrate_misplaced_page(page, vma, target_nid);
    if (migrated)
        page_nid = target_nid;

out:
    /* NUMA 폴트 통계 업데이트 */
    if (page_nid != NUMA_NO_NODE)
        task_numa_fault(last_cpupid, page_nid,
                       1, flags);
    return 0;
}

7.3 튜닝 파라미터

# Automatic NUMA Balancing 활성/비활성
$ sysctl kernel.numa_balancing
kernel.numa_balancing = 1                   # 1=활성, 0=비활성
# 스캔 주기 (ms) — 폴트가 없으면 점점 늘어남
$ sysctl kernel.numa_balancing_scan_delay_ms
kernel.numa_balancing_scan_delay_ms = 1000  # 초기 스캔 지연
$ sysctl kernel.numa_balancing_scan_period_min_ms
kernel.numa_balancing_scan_period_min_ms = 1000  # 최소 스캔 주기
$ sysctl kernel.numa_balancing_scan_period_max_ms
kernel.numa_balancing_scan_period_max_ms = 60000 # 최대 스캔 주기
# 한 번에 스캔할 페이지 수
$ sysctl kernel.numa_balancing_scan_size_mb
kernel.numa_balancing_scan_size_mb = 256    # MB 단위
# 프로세스별 NUMA 폴트 통계
$ cat /proc/<pid>/sched | grep numa
numa_pages_migrated                          :              12345
numa_preferred_nid                           :              0
total_numa_faults                            :              67890

NUMA Balancing 비활성화가 좋은 경우: 1) 이미 numactl --membind로 메모리를 명시적으로 바인딩한 경우, 2) 대규모 인메모리 DB(Redis, memcached)에서 마이그레이션 오버헤드(Overhead)가 크면 성능 저하, 3) 실시간(Real-time)(RT) 워크로드에서 NUMA fault의 지연 시간 편차가 허용 불가, 4) KVM 게스트에서호스트의 NUMA balancing과 충돌할 수 있음. # 운영체제

8. NUMA-aware 스케줄링

CFS 스케줄러(Scheduler)는 NUMA 토폴로지를 인식하여 태스크를 배치합니다. 스케줄링도메인(sched_domain) 계층이 NUMA 거리를 반영합니다.

8.1 스케줄링 도메인 계층

스케줄링 도메인의 전체 계층 구조(SMT → MC → CL → DIE → NUMA), SD 플래그 상세, EAS(Energy Aware Scheduling) 등은 CPU 토폴로지 — 스케줄링 도메인에서 상세히 다룹니다. # 분산 및 클라우드 컴퓨팅

8.2 태스크 선호 노드

/* kernel/sched/fair.c — NUMA 폴트 기반 선호 노드 결정 */

/*
 * task_struct에서 NUMA 관련 필드:
 */
struct task_struct {
    ...
    int                          numa_preferred_nid;  /* 선호 노드 */
    unsigned long                numa_scan_seq;       /* 스캔 시퀀스 */
    unsigned long                numa_scan_period;    /* 현재 스캔 주기 */
    unsigned long                numa_scan_offset;    /* 스캔 오프셋 */
    struct numa_group            *numa_group;         /* NUMA 그룹 */
    unsigned long                *numa_faults;        /* 노드별 폴트 카운터 */
    unsigned long                total_numa_faults;
    unsigned long                numa_pages_migrated;
    ...
};

/*
 * task_numa_fault()가 폴트 이력을 분석하여
 * 가장 많은 메모리 접근이 발생하는 노드를
 * numa_preferred_nid로 설정합니다.
 *
 * CFS의 wake_affine()과 find_idlest_group()은
 * numa_preferred_nid를 참고하여 태스크 배치를 결정합니다.
 */

8.3 NUMA 그룹

/*
 * NUMA 그룹은 메모리를 공유하는 태스크들을 묶어서
 * 함께 같은 노드로 마이그레이션합니다.
 *
 * 예: 멀티스레드 애플리케이션의 스레드들이
 *     같은 공유 메모리를 접근하면 하나의 NUMA 그룹으로 묶임
 *     → 스케줄러가 그룹 전체를 같은 노드에 배치하려 함
 */

struct numa_group {
    refcount_t       refcount;
    spinlock_t       lock;
    int              nr_tasks;       /* 그룹 내 태스크 수 */
    pid_t            gid;            /* 그룹 ID */
    int              active_nodes;   /* 활성 노드 수 */
    struct rcu_head  rcu;
    unsigned long    total_faults;
    unsigned long    max_faults_cpu;
    unsigned long    faults[];       /* 노드별 집계된 폴트 */
};

9. 페이지 마이그레이션

NUMA 페이지 마이그레이션은 페이지를 한 노드에서 다른 노드로 이동시키는 메커니즘입니다. NUMA balancing, migrate_pages() 시스템 콜, 메모리 핫플러그(Hotplug) 등에서 사용됩니다.

컴퓨터과학

9.1 마이그레이션 흐름

/*
 * 페이지 마이그레이션 단계:
 *
 * 1. 대상 노드에 새 페이지 할당
 * 2. 원본 페이지 잠금 (lock_page)
 * 3. 모든 PTE에서 원본 페이지 언매핑 (try_to_migrate)
 *    - PTE를 migration entry로 교체
 *    - 이 동안 접근하는 프로세스는 대기
 * 4. 페이지 데이터 복사 (migrate_folio / copy_highpage)
 * 5. 새 페이지로 PTE 재매핑 (remove_migration_ptes)
 * 6. 원본 페이지 해제
 */

/* mm/migrate.c — 핵심 마이그레이션 함수 (간략화) */
static int migrate_folio_move(
    free_folio_t put_new_folio,
    unsigned long private,
    struct folio *src,
    struct folio *dst,
    enum migrate_mode mode)
{
    int rc;

	/* 1. 원본 folio 잠금 */
    folio_lock(src);

	/* 2. 모든 매핑에서 PTE 제거 (migration entry 설치) */
    try_to_migrate(src, TTU_BATCH_FLUSH);

	/* 3. 파일시스템/드라이버의 migrate 콜백 호출 */
    rc = move_to_new_folio(dst, src, mode);
    if (rc == MIGRATEPAGE_SUCCESS) {
        /* 4. migration entry를 새 folio의 PTE로 교체 */
        remove_migration_ptes(src, dst, false);
    }

	folio_unlock(src);
    return rc;
}

NUMA 페이지 마이그레이션 6 단계 — 할당 / 잠금 (Lock)/ 언매핑 (Unmapping)/ 복사 / 재매핑 / 해제와 실패 경로 # 분산 및 클라우드 컴퓨팅

9.2 마이그레이션 도구

# 프로세스의 모든 페이지를 node0에서 node1로 이동
$ migratepages <pid> 0 1

# 특정 메모리 영역을 다른 노드로 바인딩 (기존 페이지도 이동)
$ numactl --membind=1 --touch ./app
# 또는 mbind() + MPOL_MF_MOVE 플래그

# 마이그레이션 통계 확인
$ cat /proc/vmstat | grep numa
numa_pte_updates 1234567      # NUMA hinting fault용 PTE 변경 수
numa_huge_pte_updates 12345  # hugepage PTE 변경 수
numa_hint_faults 567890      # NUMA hinting fault 발생 수
numa_hint_faults_local 456789 # 로컬 노드 접근 (이동 불필요)
numa_pages_migrated 98765    # 마이그레이션된 페이지 수
pgmigrate_success 98000      # 성공한 마이그레이션
pgmigrate_fail 765           # 실패한 마이그레이션

10. NUMA-aware 서브시스템

커널의 주요 서브시스템은 NUMA를 인식하여 데이터를 로컬 노드에 배치합니다. # 컴퓨터 메모리

10.1 Slab 할당기 (SLUB)

/*
 * SLUB 할당기는 노드별로 독립적인 partial slab 리스트를 유지합니다.
 *
 * struct kmem_cache_node {
 *     spinlock_t list_lock;
 *     unsigned long nr_partial;      // 부분 사용 slab 수
 *     struct list_head partial;      // partial slab 리스트
 * };
 *
 * kmem_cache는 노드별 kmem_cache_node를 배열로 관리:
 * kmem_cache->node[MAX_NUMNODES]
 *
 * 할당 흐름:
 * 1. 현재 CPU의 per-cpu slab에서 시도 (가장 빠름)
 * 2. 현재 노드의 partial 리스트에서 시도
 * 3. 다른 노드의 partial 리스트에서 시도 (cross-node)
 * 4. 새 slab 페이지 할당 (현재 노드 우선)
 */

# 노드별 slab 통계
$ cat /proc/slabinfo  # 전체 통계
$ slabinfo -N 0       # node0의 slab 정보

# slabtop으로 실시간 모니터링
$ slabtop -s c

10.2 Per-CPU 변수와 NUMA

/*
 * Per-CPU 변수는 각 CPU의 로컬 NUMA 노드에 할당됩니다.
 * pcpu_alloc()이 cpu_to_node()를 사용하여 적절한 노드에 메모리 배치.
 *
 * 부팅 시 per-cpu 영역 초기화:
 * setup_per_cpu_areas() → pcpu_embed_first_chunk()
 * → 각 CPU에 대해 해당 노드의 메모리에 per-cpu 영역 할당
 */

/* 올바른 NUMA-aware per-CPU 사용 */
DEFINE_PER_CPU(struct my_stats, cpu_stats);

/* 접근 시 preemption 비활성화 필수 (다른 CPU로 이동 방지) */
preempt_disable();
this_cpu_inc(cpu_stats.counter);   /* 로컬 NUMA 노드 접근 보장 */
preempt_enable();

/* NUMA-aware workqueue */
alloc_workqueue("my_wq", WQ_UNBOUND | WQ_NUMA, 0);
/* WQ_NUMA: work item을 제출한 CPU의 NUMA 노드에서 실행 */

10.3 네트워크 스택(Network Stack)과 NUMA

/* NIC의 NUMA 노드 확인 */
$ cat /sys/class/net/eth0/device/numa_node
0

/* IRQ를 NIC의 로컬 노드 CPU에 바인딩 (최적 성능) */
# NIC가 node0에 있으면 node0의 CPU에 IRQ 할당
$ echo 0-7 > /proc/irq/<irq>/smp_affinity_list

/* NUMA-aware sk_buff 할당 */
/* 네트워크 드라이버에서 NIC 로컬 노드의 메모리로 sk_buff 할당:
 * dev_alloc_skb() → __netdev_alloc_skb()
 *   → 현재 CPU의 page_frag 캐시 사용
 *   → NAPI 컨텍스트에서는 NIC의 로컬 노드에서 할당
 */

# ethtool로 RX/TX 큐 확인
$ ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
    RX:     0
    TX:     0
    Other:  0
    Combined:   32
Current hardware settings:
    Combined:   16

# 각 큐의 IRQ가 NIC 로컬 노드에 바인딩되었는지 확인
$ for irq in $(grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':'); do
    echo "IRQ $irq: node $(cat /proc/irq/$irq/node)"
done

11. NUMA와 메모리 회수 (Memory Reclaim)

각 NUMA 노드는 자체 kswapd 스레드(Thread)를 가지며, 노드별로 독립적으로 메모리 회수(reclaim)가수행됩니다.

# 분산 및 클라우드 컴퓨팅

/*
 * NUMA 노드별 kswapd:
 *
 * Node 0: kswapd0 → node0의 존들을 모니터링/회수
 * Node 1: kswapd1 → node1의 존들을 모니터링/회수
 *
 * 각 kswapd는 자기 노드의 워터마크를 기준으로 동작:
 * - pages_free < watermark_low → kswapd 깨어남
 * - pages_free > watermark_high → kswapd 슬립
 *
 * 문제: Node 0이 메모리 부족해도 Node 1에 충분하면
 *       시스템 전체로는 여유가 있지만 Node 0에서 OOM 발생 가능
 */

# 노드별 kswapd 확인
$ ps aux | grep kswapd
root   31  0.0  0.0  0  0 S  ? 0:05 [kswapd0]
root   32  0.0  0.0  0  0 S  ? 0:03 [kswapd1]

# 노드별 워터마크 확인
$ cat /proc/zoneinfo | grep -A5 "Node 0, zone   Normal"
Node 0, zone   Normal
  pages free     12057500
        boost    0
        min      16384
        low      20480
        high     24576

11.1 Zone Reclaim Mode

# zone_reclaim_mode — 로컬 노드 메모리 부족 시 동작 제어
$ sysctl vm.zone_reclaim_mode
vm.zone_reclaim_mode = 0

# 비트 플래그:
# 0 (기본): 로컬 노드 부족 시 리모트 노드에서 할당 (대부분의 경우 최적)
# 1 (RECLAIM_ZONE):  로컬 존에서 페이지 회수 시도
# 2 (RECLAIM_WRITE): 더티 페이지 쓰기 후 회수
# 4 (RECLAIM_UNMAP): 매핑된 페이지도 언매핑 후 회수

# zone_reclaim_mode=1이 유리한 경우:
# - NUMA ratio가 매우 큰 시스템 (3x 이상)
# - 메모리 접근 패턴이 극도로 로컬한 워크로드
# - 파일 캐시보다 애플리케이션 데이터가 중요한 경우

# 대부분의 경우 zone_reclaim_mode=0이 권장됨:
# - 리모트 노드 할당 비용 < 페이지 회수 비용
# - 파일 캐시 유지가 전체 성능에 유리

12. MNUMA-aware I/O

PCIe 장치(NVMe SSD, GPU, NIC 등)는 특정 NUMA 노드에 물리적으로 연결됩니다. I/O 요청이 장치와 다른NUMA 노드에서 발생하면 인터커넥트를 경유하여 지연이 증가하고 대역폭이 감소합니다. 고성능 I/O 워크로드에서는 장치의 NUMA 친화성(Affinity)을 반드시 고려해야 합니다. # 컴퓨터 메모리

11.1 NVMe와 NUMAYocto Project 소개

# NVMe 장치의 NUMA 노드 확인
$ cat /sys/block/nvme0n1/device/numa_node
0
$ cat /sys/block/nvme1n1/device/numa_node
1

# NVMe 큐의 IRQ가 올바른 노드에 바인딩되었는지 확인
$ for irq in $(grep nvme0 /proc/interrupts | awk '{print $1}' | tr -d ':'); do
    echo "IRQ $irq → node $(cat /proc/irq/$irq/node), CPUs: $(cat /proc/irq/$irq/smp_affinity_list)"
done

# 최적 설정: NVMe 큐당 1개 IRQ, 로컬 노드 CPU에 매핑
# io_uring/fio에서 NUMA 인식 I/O 테스트
$ numactl --cpunodebind=0 --membind=0 fio \
    --ioengine=io_uring --direct=1 --bs=4k --iodepth=128 \
    --filename=/dev/nvme0n1 --rw=randread --numjobs=8
# 비교: --cpunodebind=1 (리모트 노드)로 실행하면 IOPS 10-30% 감소

11.2 블록 장치(Block Device) 레이어와 NUMA

/*
 * 블록 장치의 NUMA-aware 동작:
 *
 * 1. blk-mq (Multi-Queue Block Layer):
 *    - 하드웨어 큐(hctx)가 CPU별로 매핑
 *    - hctx->numa_node로 큐의 NUMA 친화성 설정
 *    - 요청 메모리를 큐의 로컬 노드에서 할당
 *
 * 2. I/O 스케줄러 (mq-deadline, bfq, kyber):
 *    - 요청 병합/정렬에 NUMA 고려 없음 (장치 레벨 최적화)
 *    - 그러나 I/O 제출 CPU의 NUMA 위치가 성능에 영향
 *
 * 3. Page Cache와 NUMA:
 *    - 파일 읽기 시 page cache는 읽기 CPU의 로컬 노드에 할당
 *    - 여러 노드에서 같은 파일 접근 시 NUMA balancing 가능
 */

/* block/blk-mq.c — NUMA-aware 하드웨어 큐 매핑 */
static int blk_mq_hw_ctx_set_numa_node(
    struct blk_mq_hw_ctx *hctx,
    struct blk_mq_tag_set *set)
{
    /* 장치의 NUMA 노드에 큐를 매핑 */
    hctx->numa_node = set->numa_node;
    /* 큐의 요청 메모리를 이 노드에서 할당 */
    return 0;
}

# blk-mq NUMA 설정 확인
$ cat /sys/block/nvme0n1/queue/numa_node
0

irqbalance와 NUMA: irqbalance 데몬은 기본적으로 NUMA 토폴로지를 인식하여 IRQ를 장치의 로컬 노드에배분합니다. 그러나 고성능 환경에서는 irqbalance를 비활성화하고 수동으로 /proc/irq/*/smp_affinity를 설정하는것이 더 안정적입니다. 특히 DPDK나 SPDK를 사용하는 경우 IRQ 바인딩을 직접 관리해야 합니다. # 컴퓨터 과학

12. CXL과 이종 NUMA

CXL( Compute Express Link)은 CPU에 외부 메모리를 연결하여 NUMA 노드로 노출하는 새로운 인터커넥트기술입니다. CXL 메모리는 로컬 DRAM보다 지연이 크지만, 용량 확장과 비용 효율성을 제공합니다.

12.1 CXL 메모리 토폴로지

# CXL 메모리 노드 확인
$ dmesg | grep cxl
cxl_acpi ACPI0017:00: CXL region registered
cxl_mem mem0: CXL Type 3 device, 256 GB

# CXL 노드의 HMAT (Heterogeneous Memory Attribute Table) 정보
$ cat /sys/devices/system/node/node2/access0/initiators/read_latency
170
$ cat /sys/devices/system/node/node2/access0/initiators/read_bandwidth
32000

12.2 Weighted Interleave (v6.9+)

/*
 * CXL처럼 노드 간 대역폭이 다른 이종 NUMA 환경에서는
 * 단순 라운드-로빈 인터리브가 비효율적입니다.
 *
 * Weighted Interleave는 노드별 대역폭 비율에 맞춰
 * 페이지를 가중 분산합니다.
 *
 * 예: Node0 (DRAM, 50GB/s) + Node2 (CXL, 16GB/s)
 * 가중치: Node0=3, Node2=1
 * → 4페이지 중 3페이지는 Node0, 1페이지는 Node2에 할당
 */

# 가중치 설정 (sysfs)
$ echo 3 > /sys/kernel/mm/mempolicy/weighted_interleave/node0
$ echo 1 > /sys/kernel/mm/mempolicy/weighted_interleave/node2

# 프로세스에 weighted interleave 정책 적용
# set_mempolicy(MPOL_WEIGHTED_INTERLEAVE, nodemask, maxnode)
$ numactl --weighted-interleave=0,2 ./memory_intensive_app

MPOL_WEIGHTED_INTERLEAVE는 메모리 정책(Memory Policy) 관점에서 MPOL_INTERLEAVE의 상위호환입니다. 차이는 "다음 노드를 어떤 비율로 고를지"를 단순 라운드-로빈이 아니라 sysfs 가중치로선택한다는 점뿐이며, 익명 페이지(Anonymous Page)와 공유 메모리(Shared Memory)는 faulting address의페이지 오프셋(Offset)을 기준으로, page cache는 태스크별 카운터를 기준으로 분산된다는 큰 구조는 그대로유지됩니다. # 분산 및 클라우드 컴퓨팅

할당 대상	MPOL_INTERLEAVE	WEIGHTED_INTERLEAVE	운영 해석
익명 페이지 / 공유 메모리	faulting address의 페이지 오프셋을nodemask에 라운드-로빈 적용	같은 오프셋 경로를 사용하되 노드 선택 비율만 가중치로 조정	대형 배열, CXL 혼합 메모리처럼 주소 범위가 뚜렷한 워크로드에서 해석이 쉽습니다.
page cache	태스크별 interleave 카운터로 노드 순환	같은 카운터 경로를 사용하되 비율만 가중치에 맞춰 변경	파일 읽기 순서, readahead, 제출 스레드 수에 따라 분산 모양이 달라질 수 있습니다.
정규 파일의MAP_SHARED 매핑	VMA 정책이 아니라task 정책 또는 system default policy를 따릅니다.	가중치 정책도 동일한 예외를 가집니다.	mbind()를 걸었다고 해서 shared file page cache에 그대로 적용된다고 보면 안 됩니다.

12.3 메모리 티어링 (Memory Tiering)

메모리 티어링 — DRAM(Tier 0) 과 CXL(Tier 1) 간 자동 프로모션 / 디모션 흐름과 트리거 조건

# 칩 및 프로세서

/*
 * 커널 메모리 티어링 (v5.18+):
 *
 * Tier 0 (Fast): Local DRAM (Node 0, 1)
 * Tier 1 (Slow): CXL Memory (Node 2) / 영구 메모리 (PMEM)
 *
 * 핫 페이지는 Tier 0으로 프로모션
 * 콜드 페이지는 Tier 1로 디모션
 *
 * kswapd가 Tier 0 메모리 부족 시:
 * - 콜드 페이지를 Tier 1으로 디모션 (기존: swap/discard)
 * - Tier 1에서 핫 접근 감지 시 Tier 0으로 프로모션
 */

# 디모션 타겟 설정
$ cat /sys/devices/system/node/node0/memtier
1
$ cat /sys/devices/system/node/node2/memtier
2

# 노드 간 디모션 경로
$ cat /sys/devices/system/node/node0/demotion_targets
2    # Node 0의 콜드 페이지는 Node 2(CXL)로 이동

# 디모션 활성화
$ echo 1 > /sys/kernel/mm/numa/demotion_enabled

# 프로모션 통계
$ cat /proc/vmstat | grep pgpromote
pgpromote_success 12345     # Tier 1 → Tier 0 프로모션 성공
pgdemote_kswapd 67890       # kswapd에 의한 디모션
pgdemote_direct 1234        # direct reclaim에 의한 디모션

참고: CXL.mem/cache/io 프로토콜, Type1/2/3 장치, drivers/cxl/ 구조, memory_tier 자동demotion/promotion, LLM KV 캐시 CXL 배치는 CXL 메모리 페이지에서 자세히 다룹니다. # 컴퓨터 메모리

컴퓨터 메모리

13. 가상화 (Virtualization)와 vNUMA

KVM 가상화 환경에서 게스트 VM에 NUMA 토폴로지를 노출하면 게스트 OS가 NUMA-aware 최적화를수행할 수 있습니다.

# QEMU/KVM에서 vNUMA 설정
$ qemu-system-x86_64 \
    -smp 16,sockets=2,cores=4,threads=2 \
    -m 16G \
    -object memory-backend-ram,size=8G,id=ram0,host-nodes=0,policy=bind \
    -object memory-backend-ram,size=8G,id=ram1,host-nodes=1,policy=bind \
    -numa node,memdev=ram0,cpus=0-7,nodeid=0 \
    -numa node,memdev=ram1,cpus=8-15,nodeid=1 \
    -numa dist,src=0,dst=1,val=21 \
    ...

# libvirt XML에서 vNUMA 설정
<cpu>
  <numa>
    <cell id='0' cpus='0-7' memory='8388608' unit='KiB'/>
    <cell id='1' cpus='8-15' memory='8388608' unit='KiB'/>
  </numa>
</cpu>
<numatune>
  <memory mode='strict' nodeset='0-1'/>
  <memnode cellid='0' mode='strict' nodeset='0'/>
  <memnode cellid='1' mode='strict' nodeset='1'/>
</numatune>

vNUMA 핀닝: 게스트의 vNUMA 노드를 호스트의 물리 NUMA 노드에 고정(pin)하는 것이 중요합니다. 핀닝없이 게스트의 vCPU가 호스트의 다른 노드로 마이그레이션되면, 게스트 내부에서 "로컬"이라고 인식한메모리가 실제로는 호스트의 리모트 노드에 있게 되어 성능이 급격히 저하됩니다. # 칩 및 프로세서

14. 성능 분석과 최적화

14.1 perf로 NUMA 분석

# NUMA 관련 하드웨어 카운터 수집
$ perf stat -e \
    node-loads,node-load-misses,\
    node-stores,node-store-misses \
    -- ./my_application
 Performance counter stats for './my_application':
     142,857,391      node-loads          # 메모리 로드 총 수
       1,234,567      node-load-misses    # 리모트 노드 로드 (0.86%)
      98,234,567      node-stores
         345,678      node-store-misses   # 리모트 노드 스토어
# NUMA 미스 비율이 높은 함수 프로파일링
$ perf record -e node-load-misses -g -- ./my_application
$ perf report --sort=dso,symbol
# perf c2c — NUMA false sharing / remote access 분석
$ perf c2c record -- ./my_application
$ perf c2c report --stdio
=================================================
           Shared Data Cache Line Table
=================================================
       Num     RmtHitm  LclHitm    Stores  ...
  ----- -------- ------- ------- --------
     0      1234     56    7890  ...
     Address: 0x7f8a...
     Source:  my_struct+0x40 (my_module.c:123)

perf 도구를 활용해 NUMA 원격 접근(Remote Access)과 False Sharing을 실전에서 분석하는 훌륭한 워크플로우 예시입니다.

출력 데이터에서 발견할 수 있는 핵심 포인트와 실무적 해석을 정리해 드립니다.

(1) perf stat: 전반적인 NUMA 건강 상태 측정

  142,857,391  node-loads
    1,234,567  node-load-misses  # 리모트 노드 로드 (0.86%)

해석: 메모리 읽기 중 타 노드의 메모리를 참조한 비율(Remote Load)이 0.86%로 매우 낮습니다.
결론: 애플리케이션의 메모리 할당 정책(Memory Affinity)이 잘 유지되고 있으며, 일반적인 메모리 접근 면에서는 NUMA 바인딩 이슈가 거의 없는 우수한 상태입니다.

(2) perf record / report: 원인 함수 타겟팅

node-load-misses 비율이 전체적으로 낮더라도, 특정 핫스팟 함수가 병목을 유발하는지 확인할 때 유용합니다.
Callgraph(-g) 옵션을 함께 사용하여 어떤 함수 호출 경로에서 Remote Read가 발생하는지 핀포인트로 찾아낼 수 있습니다.

(3) perf c2c (Cache-to-Cache): True / False Sharing 분석

perf c2c는 단순 메모리 미스를 넘어 캐시 라인(64 Byte) 단위의 캐시 바운싱(HITM: Hit In Modified Cache)을 추적합니다.

Shared Data Cache Line Table
Num   RmtHitm  LclHitm
 0     1234      56    Address: 0x7f8a...  Source: my_struct+0x40 (my_module.c:123)

RmtHitm (Remote Hit Modified) = 1,234회:
- 의미: 다른 NUMA 노드의 CPU 캐시에 들어있던 '수정된(Modified)' 캐시 라인을 가져오느라 심각한 레이턴시(Interconnect 통신)가 발생한 횟수입니다.
- 전체 Remote Load Miss(123만 회) 중 상당수가 이 특정 구조체 주소(my_struct+0x40)에서 집중적으로 터지고 있습니다.
원인 (False Sharing 가능성):
- my_struct 내의 특정 64바이트 캐시 라인 안에 Node 0의 CPU가 자주 쓰는 변수와 Node 1의 CPU가 자주 쓰는 변수가 같이 묶여 있을 확률이 높습니다.

️ 해결 방안 (Code-Level Fix)

perf c2c로 찾은 my_struct+0x40의 False Sharing을 해결하려면 캐시 라인 정렬(Cache Line Alignment)을 적용해야 합니다.

C/C++ 구조체 패딩 적용 예시

struct my_struct {
    /* Node 0 CPU들이 자주 쓰는 변수 */
    uint64_t node0_counter;

    /* 64 바이트 경계로 정렬하여 캐시 라인을 분리 */
    alignas(64) uint64_t node1_counter; 
};

이렇게 정렬해주면 두 변수가 서로 다른 캐시 라인에 위치하게 되어, 타 노드 CPU가 값을 변경하더라도 내 캐시 라인이 Invalidate(무효화)되는 현상을 완전히 막을 수 있습니다.

14.2 numastat 분석

# 시스템 전체 NUMA 통계
$ numastat
                           node0           node1
numa_hit               142857391       98234567   # 의도한 노드에서 할당 성공
numa_miss                1234567        2345678   # 의도한 노드 실패 → 다른 노드
numa_foreign             2345678        1234567   # 다른 노드의 miss가 여기서 충족
interleave_hit           3456789        3456789   # interleave 정책 적중
local_node             139400824       95888889   # 로컬 CPU에서 로컬 메모리 할당
other_node               4690134        4690356   # 리모트 CPU에서 로컬 메모리 할당
# 높은 numa_miss → NUMA 정책 조정 필요
# 높은 other_node → 태스크가 잘못된 노드에서 실행 중
# numa_miss / numa_hit 비율이 5% 이상이면 최적화 검토
# 프로세스별 NUMA 메모리 분포
$ numastat -p <pid>
$ numastat -c qemu-kvm   # 특정 프로세스 이름으로 조회

numastat을 통해 시스템 레벨 및 프로세스 레벨에서 NUMA 할당 불균형을 진단하는 명확한 기준을 보여주는 자료입니다.

표시해주신 주석의 핵심 내용을 커널 메모리 할당 매커니즘과 연관 지어 정리해 드립니다.

(1) numastat 카운터 상호 관계 분석

numastat 결과는 커널 내부 메트릭을 보여주며, 세 카운터 간에는 다음과 같은 방정식이 성립합니다.

numa_miss(A) = numa_foreign(B)
- Node 0에서 메모리를 할당하려고 했으나 실패하여(numa_miss on Node 0), 대신 Node 1의 메모리를 할당받은 경우(numa_foreign on Node 1), 두 수치는 1:1로 대칭을 이룹니다.
local_node vs other_node
- local_node: 해당 노드의 CPU가 실행 중일 때, 자신 노드의 메모리를 할당받은 횟수 (가장 최적).
- other_node: 원격(Remote) CPU에서 실행 중인 프로세스가 이 노드의 메모리를 할당받은 횟수.

(2) 진단 유형별 해결책

① numa_miss 비율이 높음 (메모리 부족 문제)

원인: 로컬 노드의 메모리가 부족하여 커널이 어쩔 수 없이 타 노드의 메모리를 할당한 경우입니다.
해결책:
- 프로세스의 메모리 사용량을 줄이거나, 노드 간 메모리 균형을 맞춥니다.
- 복수 노드에 메모리를 균등히 분산시켜 할당하는 interleave 정책 적용:
- Bash
```
$ numactl --interleave=all ./my_application
```

② other_node 비율이 높음 (CPU affinity 문제)

원인: 메모리는 로컬에 잘 할당되었으나, OS 스케줄러가 프로세스/스레드를 타 노드의 CPU로 마이그레이션하여 실행 중인 경우입니다.

해결책:

프로세스가 특정 노드의 CPU에서만 실행되도록 CPU Affinity를 강제 고정합니다:

Bash

# Node 0의 CPU 및 메모리에 고정
$ numactl --cpunodebind=0 --membind=0 ./my_application

# 또는 taskset으로 CPU 코어 직접 지정
$ taskset -c 0-7 ./my_application

(3). 실무 가이드: numastat -p <pid> 활용

VM(QEMU/KVM)이나 대용량 DB(PostgreSQL, MySQL) 운용 시, 프로세스 단위의 노드 균형을 체크하는 데 유용합니다.

$ numastat -p 12345
Per-node process memory usage (in MBs)
Node 0       Node 1        Total
------       ------        -----
Huge          16384        16384        32768
Heap           1024            4         1028
Stack             2            2            4
Private        2048         2048         4096
-----------------------------------------
Total         19458        18438        37896

체크 포인트: 특정 노드로 메모리가 치우쳐 한쪽 노드만 Swap out이 발생하는 현상(NUMA imbalance)을 사전에 감지하고 차단할 수 있습니다.

14.3 메모리 대역폭/지연 측정 도구

# ============ Intel MLC (Memory Latency Checker) ============
# 노드별 지연 시간과 대역폭 정밀 측정 (Intel 공식 도구)
$ mlc --latency_matrix
Measuring idle latencies (in ns)...
        Numa node
Numa node    0       1
    0      81.2   139.5
    1     139.8    80.9
$ mlc --bandwidth_matrix
Measuring Memory Bandwidths (MB/sec)...
        Numa node
Numa node    0       1
    0    51200   24800    # 리모트 대역폭 ~48% 감소
    1    24600   51100
# 부하 하 지연 (loaded latency) — 실제 워크로드 시뮬레이션
$ mlc --loaded_latency
Measuring Loaded Latencies...
Inject Delay  Latency   Bandwidth
===========   =======   =========
  00000       215.3     48123     # 최대 부하 시 지연 급증
  00100       105.2     42100
  02000        83.1     12340     # 저부하 시 기본 지연
# ============ STREAM Benchmark ============
# 노드별 메모리 대역폭 측정
$ numactl --cpunodebind=0 --membind=0 ./stream_c.exe
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           47231.2     0.013489     0.013472     0.013510
Scale:          47180.5     0.013503     0.013487     0.013525
Add:            52410.8     0.018253     0.018230     0.018280
Triad:          52390.1     0.018260     0.018237     0.018290
# 리모트 노드 대역폭 비교
$ numactl --cpunodebind=0 --membind=1 ./stream_c.exe
# → Triad가 ~25000 MB/s로 약 50% 감소 (리모트 메모리 접근)
# ============ lmbench ============
# 메모리 지연 프로파일 (stride별)
$ numactl --cpunodebind=0 --membind=0 lat_mem_rd 256m 512
# 배열 크기별 접근 지연 측정
# L1 hit: ~1ns, L2 hit: ~4ns, L3 hit: ~12ns, DRAM: ~80ns
# ============ numactl --hardware (빠른 확인) ============
$ numactl --hardware
# 가장 빠른 NUMA 토폴로지 확인 방법
# 노드 수, CPU 매핑, 메모리 크기, 거리 매트릭스 한 번에 확인

리눅스 환경에서 NUMA 성능 저하와 병목을 정밀하게 진단하기 위해 사용하는 업계 표준 벤치마크 도구 3대장(Intel MLC, STREAM, lmbench)을 통한 측정 및 핵심 데이터 해석법입니다.

실제 하드웨어 튜닝 및 성능 분석 시 이 로그들을 어떻게 해석하고 조치해야 하는지 요약해 드립니다.

(1) Intel MLC(Memory Latency Checker): NUMA 레이턴시 & 대역폭의 절대적 기준. 하드웨어의 한계치와 부하 특성 파악

# 1) --latency_matrix & --bandwidth_matrix
Local (0→0): 81.2 ns / 51,200 MB/s
Remote (0→1): 139.5 ns / 24,800 MB/s  (지연 ~72% 증가, 대역폭 ~51% 감소)

하드웨어 제약 확인: UPI/Infinity Fabric 같은 노드 간 인터커넥트 버스의 대역폭 한계로 인해, 리모트 노드 접근 시 지연 시간은 약 1.7배 늘어나고 대역폭은 반토막이 납니다. 애플리케이션 아키텍처 설계 시 리모트 메모리 접근을 반드시 회피해야 하는 정량적 근거가 됩니다.
분석: 앞서 numactl --hardware에서 보았던 거리 비율(10 : 21)이 실제 시스템에서 레이턴시 약 72% 증가, 대역폭 약 51.5% 감쇄로 명확히 드러납니다.

# 2) --loaded_latency (Inject Delay에 따른 변화)
최대 부하 (00000): 215.3 ns / 48,123 MB/s
저부하 (02000):  83.1 ns / 12,340 MB/s

Loaded Latency의 위험성: 평상시 지연(Idle Latency)이 80ns인 시스템이라도, 메모리 버스에 트래픽이 몰려 포화 상태(Saturation Point)에 도달하면 지연 시간이 215.3ns로 2.5배 이상 급증합니다.
실무 적용: 메모리 집약적인 워크로드가 대역폭 한계(여기서는 약 48GB/s)에 아슬아슬하게 걸쳐 동작할 때 대기 시간이 폭발적으로 늘어나는 병목 현상을 예측할 수 있습니다.
실무적 시사점: 단순히 "Remote 메모리를 안 쓰면 된다"를 넘어, Local 메모리라 할지라도 메모리 버스 대역폭 상한선(Saturate)에 도달하면 Remote 접근보다 더 큰 지연이 발생할 수 있음을 보여줍니다.

(2) STREAM Benchmark: 실제 연산 패턴별 대역폭 검증

리눅스 커널 수준의 NUMA 바인딩(numactl)이 메모리 하위 시스템에서 실제 컴파일된 C 코드에 어떻게 투영되는지 보여줍니다.

Local Access (Node 0 $\rightarrow$ 0): Triad 기준 52,390 MB/s (MLC 이론 대역폭의 약 98% 수용)
Remote Access (Node 0 $\rightarrow$ 1): Triad 기준 ~25,000 MB/s (52% 감소)

4개 프리미티브 패턴:
- Copy (c = a): 순수 읽기/쓰기 대역폭. 단순 메모리 복사
- Scale (c = q * a): 레지스터 연산이 포함된 대역폭. 상수 곱셈 후 저장
- Add (c = a + b): 두 개의 벡터를 읽어와 하나에 쓰는 패턴. 두 벡의 합 산출
- Triad (a = b + q * c): 현업에서 가장 신뢰하는 수치로, HPC/FDM/Matrix 연산의 실제 대역폭을 대변합니다. FMA(Fused Multiply-Add) 구조로 실제 HPC/AI 워크로드 메모리 패턴과 가장 유사
검증: membind=1로 원격 노드를 찔렀을 때 Triad 결과가 딱 인터커넥트 한계치(~25,000 MB/s)로 수렴하는 것을 통해, 커널 정책이 하드웨어 수준에서 정확히 강제되고 있음을 교차 검증할 수 있습니다.

(3) lmbench (lat_mem_rd): 캐시 계층 구조 시각화

메모리 스트라이드(Stride) 접근을 통해 CPU 캐시 hierarchy부터 DRAM, Remote DRAM까지의 지연 시간을 한눈에 보여줍니다.

L1 (~1ns) → L2 (~4ns) → L3 (~12ns) → Local DRAM (~80ns) → Remote DRAM (~140ns)

Stride(보폭)의 마법: lat_mem_rd는 배열 크기를 점진적으로 늘려가며 스트라이드(예: 512바이트씩 건너뛰기) 접근을 수행합니다.
데이터 포인터 확인: 결과 데이터를 그래프로 그리면 캐시 크기 경계면(예: 32KB, 256KB, 30MB)에서 지연 시간이 계단식으로 툭툭 튀는 지점이 발생합니다. 이를 통해 하드웨어의 캐시 적중률(Cache Hit Rate) 한계선을 파악하고, 알고리즘의 Data Locality(데이터 지역성)를 하드웨어 캐시 크기에 맞게 최적화(Cache Blocking 기법 등)할 수 있습니다.

접근 계층	레이턴시 (approx.)	비고
L1d Cache	~1.0 ns	Core 내부
L2 Cache	~4.0 ns	Core 내부 / Dedicated
L3 Cache (LLC)	~12.0 ns	Package 공유
Local DRAM	~80.0 ns	Local Memory Controller
Remote DRAM	~140.0 ns	Interconnect (UPI/IF) 경유

종합 결론 및 워크플로우

시스템 도입 초기 혹은 커널 업데이트 시 numactl --hardware로 빠르게 구조를 스캔합니다.
Intel MLC를 돌려 이 시스템의 최대 성능 한계선(대역폭 임계점, 리모트 페널티)을 산출합니다.
애플리케이션 개발 시 lmbench 결과를 토대로 자료구조 크기를 캐시 라인 및 L2/L3 크기에 맞춥니다.
마지막으로 STREAM을 통해 numactl 바인딩 정책이 최적의 실측 성능을 내는지 최종 검증합니다.

정리: NUMA 최적화 골든 루틴 (Workflow)

[1. 탐색] numactl --hardware / lstopo
   └── 노드별 CPU, 메모리 배치 및 SLIT 거리 확인

[2. 검증] Intel MLC / STREAM
   └── 시스템의 Local vs Remote 성능 한계치(Baseline) 수치화

[3. 모니터링] numastat / perf stat
   └── 애플리케이션 실행 중 Remote Access / Miss 비율 감지

[4. 정밀 진단] perf c2c / perf record
   └── Cache Line 단위의 False Sharing 및 핫스팟 함수 추적

[5. 튜닝] numactl / Taskset / alignas(64)
   └── 프로세스 바인딩, 메모리 인터리빙, 구조체 패딩 적용

Intel MLC 설치: Intel MLC는 https://www.intel.com/content/www/us/en/developer/articles/tool/intelr-memory-latency-checker.html에서 무료로다운로드할 수 있습니다. AMD 시스템에서도 대부분 동작하지만, AMD 전용으로는 AMD uProf의 메모리프로파일링(Profiling) 기능을 사용할 수 있습니다. STREAM은 https://www.cs.virginia.edu/stream/에서 소스를받아 gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=...으로 컴파일합니다.

분산 및 클라우드 컴퓨팅

14.4 최적화 패턴

문제	진단	해결
높은 리모트 접근 비율	numastat의 numa_miss 비율 확인	numactl --membind 또는 --cpunodebind
NIC IRQ가 리모트 노드CPU에서 처리	cat /proc/irq/*/smp_affinity	IRQ를 NIC 로컬 노드 CPU에 바인딩
대형 해시 테이블의 불균일 접근	perf c2c 분석	numactl --interleave=all
NUMA balancing 오버헤드	/proc/vmstat의 numa_hint_faults	sysctl kernel.numa_balancing=0
한쪽 노드만 OOM	/sys/.../node*/meminfo	메모리 정책 조정, vm.zone_reclaim_mode
KVM 게스트 성능 저하	vCPU가 다른 물리 노드로 이동	vNUMA 설정 + CPU/memory 핀닝
CXL 메모리 활용 부족	numastat에서 CXL 노드 미사용	MPOL_WEIGHTED_INTERLEAVE 정책

15. 커널 설정 종합

# ===== NUMA 관련 커널 설정 종합 =====
# -- 기본 NUMA 지원 --
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y                  # AMD NUMA (K8 이상)
CONFIG_X86_64_ACPI_NUMA=y          # ACPI SRAT 기반 NUMA
CONFIG_ACPI_NUMA=y
CONFIG_NODES_SHIFT=10              # 최대 NUMA 노드 수 (2^10 = 1024)
# -- NUMA Balancing --
CONFIG_NUMA_BALANCING=y             # Automatic NUMA Balancing
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
# -- 메모리 정책 --
CONFIG_MIGRATION=y                  # 페이지 마이그레이션 지원
# -- 메모리 티어링 (CXL 등) --
CONFIG_MEMORY_TIER=y                # 메모리 티어링 프레임워크
CONFIG_DEMOTION=y                   # 콜드 페이지 디모션
# -- CXL 지원 --
CONFIG_CXL_BUS=y
CONFIG_CXL_MEM=y
CONFIG_CXL_ACPI=y
CONFIG_CXL_REGION=y
# -- HMAT (이종 메모리 속성) --
CONFIG_ACPI_HMAT=y                  # HMAT 파싱
# -- 디버깅/통계 --
CONFIG_NUMA_EMU=y                   # NUMA 에뮬레이션 (UMA에서 테스트)
CONFIG_SCHED_DEBUG=y                # 스케줄링 도메인 디버깅
CONFIG_VMSTAT=y                     # /proc/vmstat NUMA 통계

NUMA 에뮬레이션: 단일 소켓(UMA) 시스템에서 NUMA 관련 코드를 테스트하려면 커널커맨드라인에 numa=fake=4를 추가하여 가상의 4-노드 NUMA 시스템을 에뮬레이션할 수있습니다. CONFIG_NUMA_EMU=y가 필요합니다.

컴퓨터 메모리

15. 트러블 슈팅

15.1 일반적인 문제와 해결

증상	원인	진단	해결
한쪽 노드만 OOM 발생	MPOL_BIND로 특정 노드에 바인딩된 프로세스	/proc/PID/numa_maps 확인	MPOL_PREFERRED로 변경 또는 메모리 증설
성능 저하 (latency 증가)	리모트 NUMA 접근 비율 높음	perf stat -e node-load-misses	numactl --cpunodebind --membind
NUMA balancing CPU 오버헤드	잦은 NUMA hint fault 발생	perf top에서 do_numa_page 비율	kernel.numa_balancing=0
kswapd 과도한 활동(한쪽 노드)	노드 간 메모리 불균형	/proc/zoneinfo 워터마크(Watermark) 확인	vm.zone_reclaim_mode 조정
DB 쿼리 성능 불일정	NUMA balancing이 페이지 이동(Page Migration)	/proc/vmstat numa_pages_migrated	DB 프로세스에 membind적용
멀티스레드 앱 확장성 저하	스레드 간 false sharing + cross-node	perf c2c 분석	데이터 구조 padding, 노드별 분리

15.2 디버깅(Debugging) 명령 모음

# ============ 토폴로지 확인 ============
$ numactl --hardware                  # NUMA 토폴로지 전체
$ lscpu | grep -i numa                # CPU-NUMA 매핑 요약
$ lstopo --of txt                     # hwloc 상세 토폴로지
# ============ 메모리 분포 ============
$ numastat                            # 시스템 전체 NUMA 통계
$ numastat -p <pid>                   # 프로세스별 NUMA 메모리
$ cat /proc/<pid>/numa_maps           # VMA별 노드 분포
$ cat /sys/devices/system/node/node*/meminfo  # 노드별 상세 메모리
# ============ 성능 카운터 ============
$ perf stat -e node-loads,node-load-misses ./app  # NUMA 미스 측정
$ perf c2c record -- ./app            # false sharing 분석
# ============ 밸런싱 통계 ============
$ cat /proc/vmstat | grep numa        # NUMA balancing 통계
$ cat /proc/<pid>/sched | grep numa   # 프로세스 NUMA 폴트
# ============ 커널 로그 ============
$ dmesg | grep -iE "numa|srat|slit|node"  # NUMA 초기화 로그
# ============ 장치 NUMA 친화성 ============
$ cat /sys/class/net/*/device/numa_node     # NIC NUMA 노드
$ cat /sys/block/*/device/numa_node         # 블록 장치 NUMA 노드
$ lspci -vvv | grep -i "NUMA node"         # PCIe 장치 NUMA 노드

16. 흔한 실수와 안티패턴

NUMA 환경에서 자주 발생하는 성능 문제와 설정 실수를 정리합니다. 대부분 NUMA 토폴로지를 무시하거나잘못 이해한 상태에서 발생합니다.

운영체제

실수	증상	원인	해결
malloc 후 첫 접근 전 fork()	자식 프로세스의 메모리가 부모와 같은 노드에 고정	CoW(Copy-on-Write) 페이지가 부모 노드에 할당됨	fork() 후 자식에서 set_mempolicy()호출, 또는 MADV_HUGEPAGE + NUMA balancing 활용
모든 것에membind	한쪽 노드만 OOM, 다른 노드는 여유	과도한 MPOL_BIND로 노드 간 메모리 활용 불균형	대부분의 경우 MPOL_PREFERRED 또는 기본 정책이 더 나음
interleave를 모든 워크로드에 적용	지연 민감 워크로드 성능 저하	interleave는 절반의 접근이 리모트 노드	interleave는 대역폭 위주(해시 테이블, 대형 배열)에만 사용, 지연 민감 워크로드는bind/preferred
NIC IRQ가 잘못된 노드에 배치	네트워크 처리량(Throughput)저하, CPU 사용률 증가	irqbalance가 IRQ를NIC 리모트 노드로 이동	수동 IRQ 바인딩 또는 irqbalance 힌트 설정, set_irq_affinity.sh 스크립트 사용
vNUMA 없는 대형 VM	VM 내부 성능 불일정, 예측 불가능한 지연	게스트 OS가NUMA를 인식하지 못하여 최적화 불가	vNUMA 설정 + 호스트 NUMA 노드에vCPU/memory 핀닝
NUMA balancing + 명시적 바인딩 충돌	balancing이 바인딩을 무시하고 페이지 이동	커널 NUMA balancing과 사용자 정책이 경쟁	명시적 membind 사용 시 kernel.numa_balancing=0 고려
1GB HugePage의NUMA 배치 무시	hugepage가 리모트 노드에 할당, 마이그레이션 불가	1GB hugepage는 부팅 시 할당되어 마이그레이션 불가능	노드별로 /sys/.../hugepages-1048576kB/nr_hugepages 개별 설정
DB 공유 버퍼(Buffer)를MPOL_BIND로 단일 노드에 고정	해당 노드 OOM, 또는 리모트CPU에서 접근 시 느림	대형 공유 버퍼가 한 노드의 대부분을 소비	MPOL_INTERLEAVE로 분산하거나, 노드별 DB 인스턴스(Instance) 분리

16.1 코드 레벨 안티패턴

/* ❌ 안티패턴 1: NUMA 무시 대량 할당 */
void *buf = malloc(1UL << 30);  /* 1GB 할당 */
memset(buf, 0, 1UL << 30);   /* 현재 CPU의 노드에 전부 할당됨 */
/* 다른 노드의 스레드가 접근하면 모두 리모트 접근 */
/* ✅ 개선: 스레드별 첫 접근으로 분산 (first-touch) */
void *buf = mmap(NULL, size, PROT_READ|PROT_WRITE,
                MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
/* 각 스레드가 자기 영역만 초기화 → 해당 스레드의 로컬 노드에 할당 */
#pragma omp parallel for
for (int i = 0; i < num_threads; i++) {
    memset(buf + i * chunk_size, 0, chunk_size);
}
/* ❌ 안티패턴 2: 커널에서 NUMA 무시 할당 */
ptr = kmalloc(size, GFP_KERNEL);  /* 현재 CPU 노드에 할당 */
/* 이 메모리를 다른 노드의 장치 IRQ 핸들러에서 접근 */
/* ✅ 개선: 장치 노드에서 할당 */
ptr = kmalloc_node(size, GFP_KERNEL, dev_to_node(dev));
/* ❌ 안티패턴 3: per-CPU 데이터를 다른 CPU에서 빈번히 접근 */
/* per-CPU는 해당 CPU 노드의 메모리이므로
 * 다른 CPU에서 접근 시 리모트 + 캐시 바운싱 */
total += per_cpu(counter, other_cpu);  /* 느림! */
/* ✅ 개선: 합산이 필요하면 for_each_possible_cpu + 로컬 합산 */
for_each_possible_cpu(cpu)
    total += per_cpu(counter, cpu);  /* 전체 순회는 드물게만 */

First-Touch 정책: Linux의 기본 메모리 정책(MPOL_DEFAULT)은 first-touch입니다. 즉, 페이지는 처음접근(touch)하는 CPU의 NUMA 노드에 할당됩니다. 따라서 대형 배열을 한 스레드에서 초기화한 후 여러스레드에서 접근하면, 모든 메모리가 초기화 스레드의 노드에 집중됩니다. 멀티스레드 초기화(parallel first-touch) 또는 MPOL_INTERLEAVE로 분산하는 것이 핵심 패턴입니다.

분산 및 클라우드 컴퓨팅

17. NUMA 초기화 흐름

커널 부팅 시 NUMA 토폴로지 초기화는 여러 단계를 거칩니다. ACPI 테이블 파싱부터 pglist_data 구성, zonelist 빌드, kswapd 기동까지의 전체 흐름을 살펴봅니다.

NUMA 초기화 전체 흐름 — 펌웨어 (Firmware) ACPI 테이블 → 커널 파싱 → 자료구조 구성 → 런타임 관리

컴퓨터 메모리

/*
 * NUMA 초기화 흐름 (x86_64 기준)
 *
 * start_kernel()
 *   → setup_arch()
 *       → acpi_boot_init()
 *       → acpi_numa_init()            ← SRAT/SLIT 파싱
 *           → acpi_parse_srat()
 *               → acpi_parse_processor_affinity()  ← CPU→Node
 *               → acpi_parse_memory_affinity()     ← Memory→Node
 *           → acpi_parse_slit()
 *               → acpi_numa_slit_init()            ← 거리 매트릭스
 *       → numa_init()
 *           → numa_register_memblks()  ← 노드별 메모리 범위 등록
 *           → init_cpu_to_node()       ← CPU→Node 매핑 확정
 *   → mm_core_init()
 *       → build_all_zonelists()       ← zonelist 구성 (SLIT 거리 순)
 *       → free_area_init()            ← pg_data_t, zone 초기화
 *   → rest_init()
 *       → kernel_init()
 *           → smp_init()
 *               → sched_init_domains()  ← NUMA sched_domain 구성
 *           → kswapd_init()           ← 노드별 kswapd 기동
 */
/* arch/x86/mm/numa.c — NUMA 초기화 진입점 */
static int __init numa_init(int (*init_func)(void))
{
    int ret;
    /* 노드/CPU 데이터 초기화 */
    nodes_clear(numa_nodes_parsed);
    memset(&numa_meminfo, 0, sizeof(numa_meminfo));
    numa_reset_distance();
    /* ACPI SRAT/SLIT 파싱 (또는 AMD K8, devicetree 등) */
    ret = init_func();
    if (ret < 0)
        return ret;
    /* 파싱된 노드 정보로 memblock 등록 */
    ret = numa_register_memblks(&numa_meminfo);
    if (ret < 0)
        return ret;
    /* CPU→Node 매핑 확정 */
    for (i = 0; i < nr_cpu_ids; i++)
        set_cpu_numa_node(i, early_cpu_to_node(i));
    /* numa_distance[][] 유효성 검증 */
    numa_add_cpu(0);
    return 0;
}
/* mm/page_alloc.c — zonelist 구성 */
static void build_zonelists(pg_data_t *pgdat)
{
    struct zoneref *zonerefs;
    int node, local_node = pgdat->node_id;
    /*
     * 로컬 노드 우선, SLIT 거리 순으로 zonelist 구성
     * find_next_best_node()가 거리가 가까운 순서로 노드 반환
     */
    zonerefs = pgdat->node_zonelists[ZONELIST_FALLBACK]._zonerefs;
    /* 로컬 노드의 존들을 먼저 추가 */
    build_zonerefs_node(pgdat, zonerefs);
    /* 거리 순으로 리모트 노드 추가 */
    while ((node = find_next_best_node(local_node, &used_mask))
           >= 0) {
        build_zonerefs_node(NODE_DATA(node), zonerefs);
    }
}

부팅 로그 확인: dmesg | grep -iE "numa|srat|slit|node|zone"로 NUMA 초기화 과정을 확인할 수 있습니다. 특히 "SRAT: Node N PXM M" 메시지로 ACPI에서 파싱된 노드 매핑(Mapping)을, "Initmem setup node N"으로 노드별 메모리범위를 확인합니다.

분산 및 클라우드 컴퓨팅

18. NUMA와 cgroups 통합

cgroups v2의 cpuset 컨트롤러를 사용하면 컨테이너(Container)나 프로세스 그룹을 특정 NUMA 노드에 격리할수 있습니다. Kubernetes의 NUMA-aware 스케줄링도 이 메커니즘 위에 구현됩니다.

18.1 cpuset.mems — NUMA 노드 제한

# cgroups v2에서 cpuset을 사용한 NUMA 격리
# 1. cpuset 컨트롤러 활성화
$ echo "+cpuset" > /sys/fs/cgroup/cgroup.subtree_control

# 2. NUMA-격리 그룹 생성
$ mkdir /sys/fs/cgroup/numa-isolated

# 3. 사용 가능한 NUMA 노드 제한 (Node 0만 사용)
$ echo 0 > /sys/fs/cgroup/numa-isolated/cpuset.mems
$ echo 0-7 > /sys/fs/cgroup/numa-isolated/cpuset.cpus

# 4. 프로세스를 해당 cgroup에 추가
$ echo $$ > /sys/fs/cgroup/numa-isolated/cgroup.procs

# 확인: cpuset.mems.effective로 실제 적용된 노드 확인
$ cat /sys/fs/cgroup/numa-isolated/cpuset.mems.effective
0

# memory.numa_stat — cgroup의 NUMA별 메모리 사용 통계
$ cat /sys/fs/cgroup/numa-isolated/memory.numa_stat
anon N0=12345678 N1=0
file N0=8901234 N1=0
kernel_stack N0=65536 N1=0
shmem N0=0 N1=0
file_mapped N0=4567890 N1=0
file_dirty N0=12345 N1=0

18.2 Kubernetes NUMA-aware 스케줄링

# Kubernetes Topology Manager 정책 (kubelet 설정)
#
# --topology-manager-policy:
#   none       - NUMA 인식 없음 (기본)
#   best-effort - 가능하면 같은 NUMA 노드에 배치
#   restricted - NUMA 정렬 불가 시 Pod Admission 거부
#   single-numa-node - 반드시 단일 NUMA 노드에 배치
#
# Guaranteed QoS Pod + CPU Manager static 정책 사용 시:
# 1. CPU Manager가 전용 CPU 코어 할당
# 2. Topology Manager가 같은 NUMA 노드의 CPU+메모리+장치 정렬
# 3. 커널 cpuset cgroup으로 격리 적용
#
# Pod 예시:
# resources:
#   requests:
#     cpu: "4"
#     memory: "8Gi"
#   limits:
#     cpu: "4"
#     memory: "8Gi"
# → Topology Manager가 4 CPU + 8Gi를 같은 NUMA 노드에 정렬

cpuset: cpuset.mems의 상세 동작, cpuset.mems.partition을 이용한 노드 격리, isolcpus/nohz_full과의 조합은 cpusets & CPU Isolation 문서를 참조하세요.

운영체제

19. NUMA 메모리 핫플러그

서버 환경에서 메모리를 온라인 상태에서 추가/제거하는 메모리 핫플러그는 NUMA 토폴로지와 밀접합니다. 새 메모리는 특정 NUMA 노드에 속하며, 제거 시에는 해당 노드의 페이지를 먼저 마이그레이션해야 합니다.

# 메모리 핫플러그 — 노드별 메모리 블록 확인
$ ls /sys/devices/system/memory/
memory0  memory1  memory2  ...  block_size_bytes  probe

# 메모리 블록이 속한 NUMA 노드 확인
$ cat /sys/devices/system/memory/memory32/phys_device
1     # Node 1에 속함

# 메모리 블록 온라인/오프라인
$ echo online > /sys/devices/system/memory/memory32/state    # 온라인
$ echo offline > /sys/devices/system/memory/memory32/state   # 오프라인

# 오프라인 실패 시: 해당 블록에 이동 불가능한 페이지가 있음
# → movable zone에 할당된 메모리만 오프라인 가능
# → CONFIG_MEMORY_HOTREMOVE=y 필요

# 메모리를 특정 존으로 온라인 (v5.1+)
$ echo online_movable > /sys/devices/system/memory/memory32/state
# online_movable: ZONE_MOVABLE로 추가 (핫 리무브 가능)
# online_kernel:  ZONE_NORMAL로 추가 (커널 할당 가능)

/* mm/memory_hotplug.c — 핫플러그 콜백 체인 */

/*
 * 메모리 핫플러그 시 발생하는 노티파이어 이벤트:
 *
 * MEM_GOING_ONLINE  — 메모리 온라인 준비 (거부 가능)
 * MEM_ONLINE        — 메모리 온라인 완료
 * MEM_GOING_OFFLINE — 메모리 오프라인 준비 (페이지 마이그레이션)
 * MEM_OFFLINE       — 메모리 오프라인 완료
 * MEM_CANCEL_ONLINE — 온라인 취소
 * MEM_CANCEL_OFFLINE — 오프라인 취소
 */

/* 노드의 메모리가 모두 오프라인되면 node_states 업데이트 */
static void node_states_check_changes_offline(
    unsigned long nr_pages,
    struct zone *zone,
    struct memory_notify *arg)
{
    struct pglist_data *pgdat = zone->zone_pgdat;

/* 노드에 메모리가 남아있는지 확인 */
    if (!node_present_pages(pgdat->node_id)) {
        /* 메모리 없는 노드 → N_MEMORY 상태 해제 */
        arg->status_change_nid = pgdat->node_id;
    }
}

핫 리무브 제약: ZONE_NORMAL에 할당된 커널 메모리(slab, page table 등)는 마이그레이션이 불가능하므로오프라인할 수 없습니다. 핫 리무브가 필요한 환경에서는 새 메모리를 online_movable로추가하여 ZONE_MOVABLE에 배치해야 합니다. 자세한 내용은 메모리 — 핫플러그를 참조하세요.

소프트웨어

20. NUMA와 Hugepage

Hugepage 할당은 NUMA 토폴로지의 영향을 크게 받습니다. 2MB/1GB 대형 페이지는 한번 할당되면마이그레이션 비용이 매우 높으므로, 초기 배치가 특히 중요합니다.

20.1 HugeTLB 노드별 할당

# 시스템 전체 hugepage 설정 (모든 노드에 균등 분배)
$ echo 1024 > /proc/sys/vm/nr_hugepages

# 특정 노드에만 hugepage 할당 (권장)
$ echo 512 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ echo 512 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

# 노드별 hugepage 현황 확인
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages
480
$ cat /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages
510

# 1GB hugepage (노드별)
$ echo 4 > /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages

# numactl + hugepage 조합
$ numactl --membind=0 --hugepage ./database_app
# 또는 mbind() + MAP_HUGETLB 조합으로 프로그래밍

20.2 THP(Transparent Huge Pages)와 NUMA

/*
 * THP 할당 시 NUMA 고려사항:
 *
 * 1. THP는 연속 2MB 물리 메모리 필요 → 노드별 가용 연속 메모리 차이
 * 2. khugepaged가 THP 콜랩싱 시 페이지들의 노드를 확인
 *    → 다른 노드에 흩어진 4KB 페이지를 하나의 THP로 합칠 때
 *       다수 페이지가 있는 노드에 THP 할당
 * 3. NUMA balancing + THP:
 *    → 2MB 단위로 NUMA hinting fault 발생
 *    → 마이그레이션 시 2MB 복사 (4KB 대비 512배 비용)
 *    → MADV_HUGEPAGE 영역의 NUMA 배치가 특히 중요
 */

/* mm/khugepaged.c — THP collapse 시 NUMA 노드 선택 */
static int hpage_collapse_find_target_node(
    struct collapse_control *cc)
{
    int nid, target_nid, max_count = 0;

	/* 각 노드에 있는 원본 페이지 수를 집계 */
    for_each_online_node(nid) {
        if (cc->node_load[nid] > max_count) {
            max_count = cc->node_load[nid];
            target_nid = nid;
        }
    }
    /* 가장 많은 페이지가 있는 노드에 THP 할당 */
    return target_nid;
}

Hugepage: hugetlbfs 마운트(Mount) 옵션, THP 정책(always/madvise/never), khugepaged 튜닝, compound page 구조에 대한 상세 내용은 Huge Pages 문서를 참조하세요.

컴퓨터 메모리

21. NUMA 배치 최적화 플레이북

NUMA 성능 저하는 대부분 원격 메모리 접근 증가에서 시작됩니다. CPU 바인딩과 메모리 바인딩을 함께설정하고, 자동 밸런싱이 실제로 도움되는지 워크로드별로 검증해야 합니다.

워크로드 유형	권장 정책	확인 지표
지연 민감 DB	--cpunodebind + --membind	remote hit 비율, tail latency
대규모 배치 처리	interleave 또는 자동 밸런싱	처리량(Throughput)/CPU 사용률
혼합 컨테이너 환경	cgroup 메모리/CPU 격리	노드별 reclaim/oom 분포

# 배치/로컬리티 점검numactl --hardwarenumastat -p <pid>cat /proc/<pid>/numa_maps | head

22. task_numa_fault() → task_numa_placement() 체인

Automatic NUMA Balancing의 핵심 판단 경로는 do_numa_page()에서시작하여 task_numa_fault(), task_numa_placement(), task_numa_find_cpu()로 이어지는 함수 호출 체인입니다. 이 체인은NUMA hinting fault가 발생할 때마다 실행되며, 페이지와 태스크의 최적 배치를 결정합니다.

분산 및 클라우드 컴퓨팅

NUMA Balancing 판단 경로 — do_numa_page() 에서 task_numa_find_cpu() 까지의 함수 호출 체인

컴퓨터과학

task_numa_fault()는 NUMA hinting fault의 통계 수집과 배치 판단을 연결하는 핵심 함수입니다. 각 폴트에서접근된 노드 정보를 기록하고, 스캔 주기가 갱신될 때 task_numa_placement()를 호출하여 최적 노드를재계산합니다.

/* kernel/sched/fair.c — task_numa_fault() 간략화 */
void task_numa_fault(int last_cpupid, int mem_node,
                     int pages, int flags)
{
    struct task_struct *p = current;
    bool migrated = flags & TNF_MIGRATED;
    int cpu_node = cycpupid_to_nid(last_cpupid);
    int local = !!(flags & TNF_FAULT_LOCAL);
    struct numa_group *ng;
    int priv;

	/* 1. 커널 스레드나 NUMA 비활성 태스크는 무시 */
    if (!p->mm)
        return;

	/* 2. 접근이 현재 CPU의 로컬인지 판단 */
    priv = cpupid_match_pid(p, last_cpupid);
    if (!priv && !local)
        flags |= TNF_SHARED;

	/* 3. 태스크의 numa_faults[] 배열 갱신
     *    인덱스: (node * 4) + type
     *    type: NUMA_MEM(0), NUMA_CPU(1),
     *          NUMA_MEMBUF(2), NUMA_CPUBUF(3) */
    p->numa_faults[task_faults_idx(NUMA_MEMBUF, mem_node, priv)] += pages;
    p->numa_faults[task_faults_idx(NUMA_CPUBUF, cpu_node, priv)] += pages;

	/* 4. NUMA 그룹이 있으면 그룹 faults도 갱신 */
    ng = deref_curr_numa_group(p);
    if (ng) {
        spin_lock_irq(&ng->lock);
        ng->faults[task_faults_idx(NUMA_MEM, mem_node, priv)] += pages;
        ng->total_faults += pages;
        spin_unlock_irq(&ng->lock);
    }

	/* 5. 스캔 시퀀스 변경 시 → 배치 재계산 */
    if (p->numa_scan_seq != p->mm->numa_scan_seq) {
        p->numa_scan_seq = p->mm->numa_scan_seq;
        task_numa_placement(p);
    }
}

3행: last_cpupid는 이전에 이 페이지에 접근한 CPU/PID 정보로, PROT_NONE fault 시 PTE에 인코딩된 값입니다.

8행: TNF_MIGRATED 플래그는 이 폴트로 인해 페이지가 실제로 마이그레이션되었는지를 나타냅니다.

16행: cpupid_match_pid()는 이전 접근자가 현재 태스크인지 확인합니다. 같은 태스크만 접근하면 private 접근으로 분류됩니다.

18행: TNF_SHARED는 여러 태스크가 같은 페이지를 접근할 때 설정됩니다. 공유 페이지는 마이그레이션 판단이 더 보수적입니다.

22행: numa_faults[]는 4개 유형(MEM/CPU/MEMBUF/CPUBUF) × 노드 수 × 2(private/shared)로 구성됩니다. BUF 접미사가 붙은 것은 현재 스캔 주기의 버퍼입니다.

33행: numa_scan_seq가 변경되면 한 스캔 주기가 완료된 것입니다. 이때 누적된 폴트 데이터를 기반으로 task_numa_placement()가 최적 배치를 재계산합니다.

호출 빈도: task_numa_fault()는 NUMA hinting fault마다 호출되지만, task_numa_placement()는 스캔 시퀀스가 변경될때만 호출됩니다. 스캔 주기가 1초~60초이므로 placement 재계산은 상대적으로 드물게 발생하여 오버헤드를제한합니다.

23. struct numa_group 심층 분석

struct numa_group은 메모리를 공유하는 태스크들을 그룹으로 묶어, 스케줄러가 그룹 전체의 NUMA 배치를최적화할 수 있게 합니다. 멀티스레드 애플리케이션에서 같은 공유 메모리를 접근하는 스레드들이 자동으로하나의 NUMA 그룹으로 합쳐집니다.

numa_group 과 task_struct 의 NUMA 관련 필드 — 공유 메모리 접근 패턴 기반 그룹 형성

컴퓨터 메모리

/* kernel/sched/fair.c — numa_group 구조체와 태스크 NUMA 필드 */

/* numa_faults[] 배열 인덱스 계산
 * 4가지 유형 × 노드 수 × 2(private/shared) = 8 * nr_node_ids */
enum numa_faults_stats {
    NUMA_MEM = 0,      /* 메모리 노드 폴트 (페이지 위치) */
    NUMA_CPU,           /* CPU 노드 폴트 (접근한 CPU 위치) */
    NUMA_MEMBUF,        /* 현재 주기 메모리 버퍼 */
    NUMA_CPUBUF,        /* 현재 주기 CPU 버퍼 */
};

static inline int task_faults_idx(
    enum numa_faults_stats s, int nid, int priv)
{
    return NR_NUMA_HINT_FAULT_TYPES * (s * nr_node_ids + nid) + priv;
}

/* task_weight: 태스크 개별 폴트 가중치
 * 특정 노드에서의 private 폴트가 많을수록 높은 점수 */
static inline unsigned long task_weight(
    struct task_struct *p, int nid, int dist)
{
    unsigned long faults, total_faults;

	/* private + shared 폴트 합산 */
    faults = p->numa_faults[task_faults_idx(NUMA_MEM, nid, 0)] +
             p->numa_faults[task_faults_idx(NUMA_MEM, nid, 1)];
    total_faults = p->total_numa_faults;

	if (!total_faults)
        return 0;
    return 1000 * faults / total_faults;
}

/* group_weight: 그룹 전체의 폴트 가중치 */
static inline unsigned long group_weight(
    struct task_struct *p, int nid, int dist)
{
    struct numa_group *ng = deref_curr_numa_group(p);
    unsigned long faults, total_faults;

	if (!ng)
        return 0;

	faults = ng->faults[task_faults_idx(NUMA_MEM, nid, 0)] +
             ng->faults[task_faults_idx(NUMA_MEM, nid, 1)];
    total_faults = ng->total_faults;

	if (!total_faults)
        return 0;

	return 1000 * faults / total_faults;
}

4행: numa_faults[] 배열은 4가지 통계 유형(MEM, CPU, MEMBUF, CPUBUF)을 노드별, private/shared 구분으로 저장합니다. BUF 유형은 현재 스캔 주기의 임시 버퍼로, 주기 종료 시 MEM/CPU로 합산됩니다.칩 및 프로세서

15행: task_faults_idx()는 다차원 배열을 1차원으로 평탄화한 인덱스 계산 함수입니다. NR_NUMA_HINT_FAULT_TYPES은 2(private=1, shared=0)입니다.

25행: task_weight()는 특정 노드에 대한 태스크의 메모리 접근 비율을 1000분율로 계산합니다. 높을수록 해당 노드에 태스크를 배치할 이유가 강합니다.

38행: group_weight()는 numa_group 전체의 폴트를 기반으로 가중치를 계산합니다. 그룹이 있으면 개별 태스크뿐 아니라 그룹 전체의 메모리 접근 패턴을 반영하여 배치를 결정합니다.

24. NUMA 페이지 마이그레이션 경로 분석

NUMA balancing이 페이지 마이그레이션을 결정하면, migrate_misplaced_page()에서 시작되는 마이그레이션체인이 실행됩니다. 이 경로는 페이지 격리, 노드 간 복사, PTE 재매핑을 포함하며, 마이그레이션 실패 시 원래위치를 유지합니다.

/* mm/migrate.c — NUMA misplaced 페이지 마이그레이션 */
int migrate_misplaced_page(struct page *page,
                          struct vm_area_struct *vma,
                          int node)
{
    struct folio *folio = page_folio(page);
    pg_data_t *pgdat = NODE_DATA(node);
    int nr_remaining;
    unsigned int nr_succeeded;
    LIST_HEAD(migratepages);

	/* 1. 마이그레이션 속도 제한 (rate limiting)
     *    너무 많은 마이그레이션이 동시에 발생하면 성능 저하 */
    if (rate_limited_count_exceeded(pgdat))
        goto out;

	/* 2. folio 격리: LRU에서 분리
     *    마이그레이션 중 다른 경로에서 접근하지 않도록 */
    if (numamigrate_isolate_folio(pgdat, folio))
        goto out;

	list_add(&folio->lru, &migratepages);
    nr_remaining = migrate_pages(&migratepages,
                                 alloc_misplaced_dst_folio,
                                 NULL, node,
                                 MIGRATE_ASYNC,
                                 MR_NUMA_MISPLACED,
                                 &nr_succeeded);

	if (nr_remaining) {
        /* 마이그레이션 실패: 원본 folio를 LRU에 복귀 */
        if (!list_empty(&migratepages))
            putback_movable_pages(&migratepages);
    }

	return nr_succeeded;
out:
    folio_put(folio);
    return 0;
}

/* mm/migrate.c — NUMA 마이그레이션용 folio 격리 */
static bool numamigrate_isolate_folio(
    pg_data_t *pgdat, struct folio *folio)
{
    /* 노드별 마이그레이션 허용량 검사
     * numabalancing_migrate_nr_pages 초과 시 거부
     * → 한 노드에 너무 많은 페이지가 한꺼번에 몰리는 것 방지 */
    if (pgdat->numabalancing_migrate_nr_pages >
        NUMA_MIGRATION_THRESHOLD) {
        if (time_before(jiffies,
            pgdat->numabalancing_migrate_next_window))
            return true;  /* 속도 제한 */
        pgdat->numabalancing_migrate_nr_pages = 0;
        pgdat->numabalancing_migrate_next_window =
            jiffies + 2 * HZ;
    }

	/* LRU에서 folio 분리 */
    if (!folio_isolate_lru(folio))
        return true;  /* 격리 실패 */

	pgdat->numabalancing_migrate_nr_pages += folio_nr_pages(folio);
    return false;  /* 성공 */
}

14행: 속도 제한(rate limiting)은 NUMA balancing이 한 번에 너무 많은 페이지를 마이그레이션하여 시스템 성능을 저하시키는 것을 방지합니다. 2초 윈도우당 허용량을 제한합니다.분산 및 클라우드 컴퓨팅

19행: numamigrate_isolate_folio()는 folio를 LRU 리스트에서 분리합니다. 격리하지 않으면 kswapd 등 다른 경로가 동시에 같은 페이지를 조작할 수 있습니다.

23행: migrate_pages()는 범용 마이그레이션 엔진입니다. alloc_misplaced_dst_folio()가 대상 노드에서 새 folio를 할당하고, MIGRATE_ASYNC 모드로 비동기 마이그레이션을 수행합니다.

27행: MR_NUMA_MISPLACED는 마이그레이션 사유(reason)를 나타냅니다. /proc/vmstat의 pgmigrate_success/pgmigrate_fail 통계에서 사유별로 구분됩니다.

31행: 마이그레이션 실패 시 putback_movable_pages()로 원본 folio를 LRU에 복귀시킵니다. 대상 노드 메모리 부족이나 folio가 pinned 상태일 때 실패할 수 있습니다.

47행: numabalancing_migrate_next_window는 다음 윈도우 시작 시간입니다. 2초(2*HZ) 간격으로 윈도우가 갱신되며, 각 윈도우에서 마이그레이션 카운터가 초기화됩니다.

마이그레이션 비용: NUMA 페이지 마이그레이션은 페이지 데이터 복사(4KB 또는 2MB THP), PTE 언매핑/재매핑, TLB 플러시(Flush)를 수반합니다. 특히 THP의 경우 2MB를 복사해야 하므로 마이그레이션비용이 512배 증가합니다. 이 때문에 커널은 rate_limited_count_exceeded()로 마이그레이션 속도를 제한하고, 실제로 이득이 있는 경우에만 마이그레이션을 수행합니다.

25. NUMA 메모리 정책 커널 경로

set_mempolicy()와 mbind()는 결국 커널 내부의 struct mempolicy로 수렴합니다. 페이지 할당 hot path에서는 이 정책객체의 mode, flags, nodemask를 읽어 alloc_pages_mpol()이 대상 노드를 고릅니다. 다만 shared policy lookup, reference count, cpuset 재바인딩이 섞이면 사용자 공간에서 보는 "간단한 nodemask"보다 실제 경로가 더복잡해집니다.

NUMA 메모리 정책 — alloc_pages_mpol() 의 정책별 분기와 struct mempolicy 구조

컴퓨터 메모리

hot path 관점: struct mempolicy 는 참조 카운터를 가지며, task/VMA policy는 보통 fault path에서 mmap_lock 보호아래 읽힙니다. 반면 shared policy는 lookup 중 추가 참조와 잠금 경로가 필요하므로 같은 interleave/bind 정책이라도 shared memory에서는 비용이 더 높을 수 있습니다.

/* mm/mempolicy.c — set_mempolicy() 시스템 콜 경로 */
SYSCALL_DEFINE3(set_mempolicy, int, mode,
    const unsigned long __user *, nmask,
    unsigned long, maxnode)
{
    return kernel_set_mempolicy(mode, nmask, maxnode);
}

static long kernel_set_mempolicy(int mode,
    const unsigned long __user *nmask,
    unsigned long maxnode)
{
    nodemask_t nodes;
    unsigned short flags;

	/* 모드와 플래그 분리 */
    flags = mode & MPOL_MODE_FLAGS;
    mode &= ~MPOL_MODE_FLAGS;

	/* 사용자 공간 nodemask를 커널 nodemask로 복사 */
    get_nodes(&nodes, nmask, maxnode);

	return do_set_mempolicy(mode, flags, &nodes);
}

static long do_set_mempolicy(unsigned short mode,
    unsigned short flags, nodemask_t *nodes)
{
    struct mempolicy *new, *old;
    struct mm_struct *mm = current->mm;

	/* 새 mempolicy 객체 생성 */
    new = mpol_new(mode, flags, nodes);

	/* current->mempolicy 교체
     * 이후 alloc_pages()가 이 정책을 참조 */
    task_lock(current);
    old = current->mempolicy;
    current->mempolicy = new;
    task_unlock(current);

	mpol_put(old);
    return 0;
}

/* mm/mempolicy.c — 정책 기반 페이지 할당 */
struct page *alloc_pages_mpol(gfp_t gfp,
    unsigned int order, struct mempolicy *pol,
    pgoff_t ilx, int nid)
{
    struct page *page;

	switch (pol->mode) {
    case MPOL_PREFERRED:
    case MPOL_PREFERRED_MANY:
        /* 선호 노드에서 우선 시도, 실패 시 폴백 */
        nid = policy_node(gfp, pol, nid);
        break;
    case MPOL_BIND:
        /* nodemask 내에서만 할당 (zonelist 필터링) */
        gfp |= __GFP_HARDWALL;
        break;
    case MPOL_INTERLEAVE:
        /* 라운드-로빈으로 노드 선택 */
        nid = interleave_nid(pol, ilx);
        break;
    case MPOL_WEIGHTED_INTERLEAVE:
        /* 대역폭 가중치로 노드 선택 (v6.9+) */
        nid = weighted_interleave_nid(pol, ilx);
        break;
    }
    page = __alloc_pages(gfp, order, nid, policy_nodemask(gfp, pol));
    return page;
}

축약 코드 해석 주의: 위 코드는 정책별 노드 선택 분기를 이해하기 위한 간략화 예시입니다. 여기서 interleave_nid(pol, ilx)는 주로 익명 페이지와 공유 메모리의 "페이지 오프셋 기반 분산"을 상징적으로 보여줍니다. page cache는 같은 interleave 정책이라도 태스크별 카운터를 사용하므로, 파일 I/O 배치는 주소오프셋만으로 설명되지 않습니다.

분산 및 클라우드 컴퓨팅

17행: MPOL_MODE_FLAGS로 모드 값에 포함된 플래그를 분리합니다. 모드 상위 비트에 MPOL_F_STATIC_NODES 등의 플래그가 OR됩니다.

33행: mpol_new()는 struct mempolicy를 kmem_cache에서 할당하고 초기화합니다. 참조 카운터를 1로 설정합니다.

37행: current->mempolicy를 교체하면 이후 해당 태스크의 모든 페이지 할당에 새 정책이 적용됩니다. mbind()는 VMA별 정책(vma->vm_policy)을 설정하며, 이것이 태스크 정책보다 우선합니다.

52행: MPOL_PREFERRED는 policy_node()로 선호 노드를 반환하지만, 할당 실패 시 일반 zonelist 폴백이 동작합니다.

56행: MPOL_BIND는 __GFP_HARDWALL을 추가하여 cpuset/mempolicy 범위 밖 노드로의 폴백을 차단합니다.

59행: interleave_nid() 설명은 익명 페이지와 공유 메모리에 가장 직접적으로 대응합니다. 이 경우 faulting address의 페이지 오프셋(ilx)으로 nodemask를 인덱싱합니다. page cache는 별도 태스크 카운터 기반으로 분산되므로 같은 interleave 정책이어도 파일 I/O 패턴에 따라 결과가 달라질 수 있습니다.

63행: weighted_interleave_nid()는 v6.9에서 추가된 함수로, 같은 interleave 경로에서 라운드-로빈 대신 sysfs 가중치(/sys/kernel/mm/mempolicy/weighted_interleave/nodeN) 비율을 적용합니다. 익명 페이지/공유 메모리는 페이지 오프셋 기반, page cache는 태스크 카운터 기반이라는 차이는 그대로 유지됩니다. #데이터 관리

26. NUMA 스코어 계산과 노드 배치 최적화

task_numa_placement()는 태스크와 그룹의 NUMA 폴트 데이터를 분석하여 최적 노드를 결정합니다. 각 노드에대해 task_weight()와 group_weight()를 계산하고, 현재 배치와 이동 후 배치의 스코어를 비교하여 이동 여부를판단합니다.

/* kernel/sched/fair.c — task_numa_placement() 간략화 */
static void task_numa_placement(struct task_struct *p)
{
    int seq, nid, max_nid = NUMA_NO_NODE;
    unsigned long max_faults = 0;
    unsigned long fault_types[2] = { 0, 0 };
    struct numa_group *ng;

	/* 1. 스캔 시퀀스 검증 */
    seq = READ_ONCE(p->mm->numa_scan_seq);
    if (p->numa_scan_seq == seq)
        return;
    p->numa_scan_seq = seq;

	/* 2. 각 노드에 대해 스코어 계산 */
    for_each_online_node(nid) {
        unsigned long faults = 0, group_faults = 0;
        int priv;

		for (priv = 0; priv < NR_NUMA_HINT_FAULT_TYPES; priv++) {
            unsigned long diff, f_new, f_old;
            int idx = task_faults_idx(NUMA_MEM, nid, priv);

			/* 지수 이동 평균 (EMA) 적용:
             * new = old/2 + buf
             * → 최근 폴트에 더 큰 가중치 */
            f_old = p->numa_faults[idx];
            f_new = f_old / 2 + p->numa_faults[idx + 2]; /* +2 = MEMBUF */
            p->numa_faults[idx] = f_new;
            p->numa_faults[idx + 2] = 0; /* 버퍼 초기화 */

			faults += f_new;
            diff = abs(f_new - f_old);
            fault_types[priv] += f_new;
        }

		/* 3. 가장 높은 폴트 카운트를 가진 노드 추적 */
        if (faults > max_faults) {
            max_faults = faults;
            max_nid = nid;
        }

		/* 4. numa_group이 있으면 그룹 폴트도 EMA 갱신 */
        ng = deref_curr_numa_group(p);
        if (ng) {
            /* 그룹의 faults[]도 같은 EMA 방식으로 갱신 */
            update_numa_group_faults(ng, nid);
        }
    }

	/* 5. 스캔 주기 적응
     *    로컬 폴트 비율이 높으면 → 주기 증가 (스캔 빈도 감소)
     *    리모트 폴트 비율이 높으면 → 주기 감소 (더 자주 스캔) */
    update_task_scan_period(p, fault_types[0], fault_types[1]);

	/* 6. 선호 노드 갱신 — 그룹 고려 */
    ng = deref_curr_numa_group(p);
    if (ng) {
        /* 그룹이 있으면 task_numa_find_cpu()로
         * 그룹 전체의 최적 배치 탐색 */
        nid = task_numa_find_cpu(p, max_nid);
    }

	/* 현재 노드와 다른 노드가 최적이면 선호 노드 변경 */
    if (max_nid != p->numa_preferred_nid) {
        /* CFS 스케줄러가 다음 wake-up 시 이 노드를 선호 */
        sched_setnuma(p, max_nid);
    }
}

10행: numa_scan_seq는 mm_struct에 저장된 전역 시퀀스 번호입니다. task_tick_numa()가 VMA 스캔을 완료할 때마다 증가합니다. #운영체제

26행: 지수 이동 평균(EMA)을 사용하여 오래된 폴트 데이터를 점진적으로 감쇠시킵니다. f_old/2 + buf로 최근 스캔 주기의 폴트에 50% 가중치를 부여합니다.

29행: BUF(버퍼) 엔트리를 0으로 초기화하여 다음 스캔 주기의 새로운 폴트 데이터를 수집할 준비를 합니다.

36행: 모든 노드 중 가장 높은 폴트 카운트를 가진 노드(max_nid)가 태스크의 메모리가 가장 많이 집중된 노드입니다.

50행: update_task_scan_period()는 private/shared 폴트 비율에 따라 스캔 주기를 동적으로 조정합니다. 지역성이 좋으면 불필요한 스캔을 줄이고, 나쁘면 더 자주 확인합니다.

56행: task_numa_find_cpu()는 대상 노드에서 현재 태스크와 교환(swap)할 수 있는 최적의 CPU/태스크를 찾습니다. 교환 시 양쪽 태스크의 NUMA 지역성이 모두 개선되어야 합니다.

62행: sched_setnuma()는 p->numa_preferred_nid를 갱신합니다. CFS의 select_task_rq_fair()가 이 값을 참조하여 태스크를 해당 노드의 CPU에 배치합니다.

스코어 해석: task_weight()는 1000 기준 점수입니다. 예를 들어 2-노드 시스템에서 태스크가 Node 0에 800, Node 1에 200의 task_weight를 가지면, 메모리 접근의 80%가 Node 0에 집중된 것입니다. group_weight()도 같은방식으로 그룹 전체의 노드별 접근 비율을 나타냅니다. 스케줄러는 task_weight + group_weight를 종합하여 최적배치를 결정합니다.

task_numa_compare(): task_numa_find_cpu() 내부에서 각 후보 CPU의 현재 태스크와 교환(swap)했을 때의이득을 평가합니다. 교환 전후의 task_weight + group_weight 합계를 비교하여, 양쪽 모두에게 이득이 있거나총합이 증가하는 경우에만 교환을 승인합니다. 이는 한 태스크의 지역성을 개선하기 위해 다른 태스크의지역성을 희생하는 것을 방지합니다.

27. Linux 6.12 ~ 6.19 NUMA 최신 동향

CXL 상용 제품군이 확대되면서 NUMA의 의미가 "물리적으로 떨어진 소켓"에서 "다른 대역폭·지연 특성을가진 메모리 티어"로 확장되었습니다. 이에 따라 Auto NUMA balancing, memory tiering, ACPI HMAT 기반노드 속성 해석, DAMON 기반 핫/콜드 이동이 2024-2025년에 빠르게 통합되었습니다.

커널	릴리스	NUMA 주요 변경	실무 시사점
6.12 (LTS)	2024-11	WMARK_PROMO 워터마크가 /proc/zoneinfo에 노출 — DRAM-CXL 간 승격/강등 기준을 시스템 단위로 관찰 가능, NUMA 노드별 folio 통계 세분화	CXL 메모리가 포함된 호스트의 티어링 품질을 zoneinfo만으로 가시화 가능
6.13	2025-01	numa_balancing 모드가 NUMA_BALANCING_MEMORY_TIERING 확장을 공식 튜너블로 정리, ACPI HMAT 기반 access attribute가sysfs access0/1/에 표준화	콜드/핫 티어를 자동 이동하는 운영 스크립트가 배포 간 이식 가능
6.14	2025-03	메모리 핫플러그 기본 online 정책 빌드 시 선택 가능, memhp_default_online_type 부팅 파라미터 정리	CXL 메모리 핫추가 시 자동 online_movable/online_kernel선택 가능
6.15	2025-05	DAMON MIGRATE_HOT/MIGRATE_COLD 액션과 monitoring intervals auto-tuning이 NUMA 티어링과 결합, sysfs 기반 다중 마이그레이션 타깃 기반 정책 실험	DAMON으로 "핫은 DRAM, 콜드는 CXL"을 선언적으로 지정하는 운영이 가능
6.16	2025-07	CXL 2.0/3.0 Dynamic Capacity Device(DCD) 운영 인터페이스, NUMA node distance 계산 정확도 향상, numa_stat 카운터 확장	워크로드 단위로 CXL 풀을 동적으로 빌렸다 반납하는 멀티테넌트 배포가 실현 단계
6.17	2025-09	NUMA 노드별 선제적 회수(proactive reclaim) 인터페이스 추가— /sys/devices/system/node/nodeN/reclaim에 echo 512M swappiness=10 > 형식으로 노드 단위 회수 트리거 가능; NUMA 노드 알림자(notifier) 내부 API가 메모리 on/offline 알림자에서 분리 독립	CXL/PMem 혼합 시스템에서 특정 노드만 선택적으로 회수하는 운영 스크립트 작성 가능. cpuset 단일 노드 환경에서 불필요한 NUMA 밸런싱 오버헤드 방지
6.18	2025-11	NUMA 제약으로 인한 kswapd 스래싱 방지 — 메모리 압박이 해소되거나 강등(demotion) 설정이 변경될 때 kswapd 재활성화 로직 개선; page_alloc 경로에서 NUMA 제약 하의 불필요한kswapd 트리거 감소	NUMA 제약 환경(cpuset 또는mbind BIND 정책)에서 kswapd의 불필요한 스왑(Swap) 폭풍(swap storm) 발생 빈도 감소
6.19	2026-02	kmalloc_large()의 NUMA 메모리 정책 무시 회귀 버그 수정— mm/slab_common.c의 정리 과정에서 large kmalloc 경로가 mempolicy를 무시하고 로컬 노드만 선호하는 문제 발생, 수정 커밋으로 재적용	대형 메모리 할당(kmalloc 4KB 이상)이 BIND/INTERLEAVE 정책을 올바르게 따르게 됨. AMD Threadripper 등 고코어 시스템에서 모듈 로딩 시간이 최대60% 늘어나는 증상 해소

핵심 요약: (1) 6.12 이후 NUMA와 메모리 티어링은 동일한 인프라를 공유합니다. CPU-less 노드를 "콜드티어"로 쓰는 구성이 표준화되었습니다. (2) numactl -H, daxctl list, cxl list를 함께 보는 것이 현실적 디버깅조합입니다. (3) DAMON·numa_balancing·사용자 정의 migration daemon을 동시에 켜면 정책 충돌이 발생하므로한 축을 주 컨트롤러로 지정하세요. (4) 6.17부터 /sys/devices/system/node/nodeN/reclaim으로 노드 단위 선제적회수가 가능합니다.

# 컴퓨터과학

28. 참고자료

28.1 커널 문서

NUMA Memory Policy — NUMA 메모리 정책 관리자 가이드입니다
NUMA — NUMA 내부 구현 문서입니다
NUMA Performance — NUMA 성능 측정 및 튜닝 문서입니다

28.2 Man 페이지

mbind(2) — 메모리 영역에 NUMA 정책을 설정하는 시스템 콜입니다
set_mempolicy(2) — 프로세스 기본 NUMA 메모리 정책을 설정합니다
numa(7) — NUMA 아키텍처 개요 man page입니다

28.3 LWN 기사

NUMA scheduling progress — NUMA 인식 스케줄링 개선 진행 상황입니다 (2013)
Automatic NUMA balancing — 자동 NUMA 밸런싱 메커니즘을 설명합니다 (2012)
Memory tiering — CXL 기반 메모리 티어링과 NUMA의 관계를 다룹니다 (2022)
NUMA in a day — NUMA 개념을 종합적으로 정리한 기사입니다 (2014)

28.4 커널 소스 코드

mm/mempolicy.c — NUMA 메모리 정책 구현입니다
mm/migrate.c — NUMA 페이지 마이그레이션 구현입니다
kernel/sched/fair.c — CFS 스케줄러 내 NUMA 밸런싱 로직입니다

# 관련 문서

NUMA와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

# 분산 및 클라우드 컴퓨팅

메모리 관리 개요 — Buddy Allocator, 존 구조, 페이지 테이블(Page Table) 등 NUMA의 기반이 되는 메모리관리 기초
메모리 관리 개요 — 메모리 회수, OOM Killer, 메모리 핫플러그 등 NUMA 환경의 고급 메모리 관리
CPU 토폴로지 — AMD CCX/CCD, Intel Tile, ARM DynamIQ, 스케줄링 도메인 계층 등 NUMA 토폴로지의하드웨어 기반
프로세스 스케줄러 — CFS의 NUMA-aware 태스크 배치, 로드 밸런싱, wake_affine 등 스케줄링 관점
CPU 캐시 — L1/L2/L3 캐시 계층, false sharing, 캐시 라인(Cache Line) 정렬 등 NUMA 성능에 영향을 미치는 캐시 동작
Slab 할당기 — SLUB의 노드별 partial 리스트, per-CPU 캐시, kmalloc_node() 등 NUMA-aware slab 할당
Per-CPU 데이터 — Per-CPU 변수의 NUMA-aware 메모리 배치와 pcpu_alloc() 메커니즘
Huge Pages — HugeTLB 노드별 할당, THP와 NUMA balancing 연동, khugepaged의 노드 선택
cpusets & CPU Isolation — cpuset.mems를 이용한 NUMA 노드 격리, isolcpus, nohz_full 조합
CXL 메모리 — CXL.mem/cache/io 프로토콜, Type1/2/3 장치, 메모리 티어링, Weighted Interleave
HMM (Heterogeneous Memory Management) — GPU/가속기와 CPU 간 NUMA 토폴로지 확장, ZONE_DEVICE, migrate_vma
데이터베이스와 커널 — DB tail latency와 NUMA 로컬리티, membind/interleave 실전 전략

Contents

핵심 요약

단계별 이해

NUMA 탄생 배경과 기초 개념

UMA에서 NUMA로 — 확장성 한계의 해결

NUMA 핵심 용어 정리

로컬 메모리와 원격 메모리의 성능 차이

NUMA가 성능에 영향을 미치는 상황

내 시스템 NUMA 현황 첫 진단

NUMA 하드웨어 토폴로지

NUMA Ratio와 영향

AMD EPYC NPS(Nodes Per Socket) 토폴로지

Intel SNC(Sub-NUMA Clustering)

ACPI를 통한 NUMA 토폴로지 검색

SRAT (Static Resource Affinity Table)

SLIT (System Locality Information Table)

HMAT (Heterogeneous Memory Attribute Table)

토폴로지 확인 명령

커널 자료구조: pglist_data

Zonelist — 할당 폴백 순서

노드 통계 확인

NUMA 메모리 정책

정책 유형

정책 범위와 재바인딩

시스템 콜

numactl 사용

커널 내부 NUMA 할당 API

Automatic NUMA Balancing

동작 원리

NUMA Hinting Fault

튜닝 파라미터

NUMA-aware 스케줄링

스케줄링 도메인 계층

태스크 선호 노드

NUMA 그룹

페이지 마이그레이션

마이그레이션 흐름

마이그레이션 도구

NUMA-aware 서브시스템

Slab 할당기 (SLUB)

Per-CPU 변수와 NUMA

네트워크 스택(Network Stack)과 NUMA

NUMA와 메모리 회수(Memory Reclaim)

Zone Reclaim Mode

NUMA-aware I/O

NVMe와 NUMA

블록 장치(Block Device) 레이어와 NUMA

CXL과 이종 NUMA

CXL 메모리 토폴로지

Weighted Interleave (v6.9+)

메모리 티어링 (Memory Tiering)

가상화(Virtualization)와 vNUMA

성능 분석과 최적화

perf로 NUMA 분석

numastat 분석

메모리 대역폭/지연 측정 도구

최적화 패턴

커널 설정 종합

트러블슈팅

일반적인 문제와 해결

디버깅(Debugging) 명령 모음

흔한 실수와 안티패턴

코드 레벨 안티패턴

NUMA 초기화 흐름

NUMA와 cgroups 통합

cpuset.mems — NUMA 노드 제한

Kubernetes NUMA-aware 스케줄링

NUMA 메모리 핫플러그

NUMA와 Hugepage

HugeTLB 노드별 할당

THP(Transparent Huge Pages)와 NUMA

NUMA 배치 최적화 플레이북

task_numa_fault() → task_numa_placement() 체인

struct numa_group 심층 분석

NUMA 페이지 마이그레이션 경로 분석

NUMA 메모리 정책 커널 경로

NUMA 스코어 계산과 노드 배치 최적화

Linux 6.12 ~ 6.19 NUMA 최신 동향

참고자료

커널 문서

Man 페이지

LWN 기사

커널 소스 코드

AP-A2B-DSP

Jay.P Morgan — Fri, 15 May 2026 16:31:14 +0900

1. AP-DSP 사에의 A2B Transceiver 2EA

(Automotive Audio Bus)의 동작 원리 때문에 발생하는 물리적인 제약입니다.

이해를 돕기 위해 왜 2개가 필요한지, 그리고 전체 그림이 어떻게 그려지는지 쉽게 설명해 드릴게요.

1.1 왜 AD2428이 2개(혹은 그 이상) 필요할까?

는 일반적인 오디오 인터페이스(I2S)를 '장거리 전송용 특수 신호'로 포장해서 보내는 일종의 모뎀 역할을 합니다.

• i.MX8MP 측: I2S 신호를 신호로 바꿔서 내보낼 모뎀(AD2428)이 필요합니다.

• EV-21569 측: 들어온 신호를 다시 I2S로 풀어서 해석할 모뎀(AD2428)이 필요합니다.

즉, [i.MX8MP] ↔ [AD2428 #1] <--- ( 케이블) ---> [AD2428 #2] ↔ [EV-21569] 이런 구조가 되어야 합니다. 하나만 있다면 한쪽은 신호를 알아들을 장치가 없는 셈이 됩니다.

1.2 전체 연결 구성도 (구축해야 할 모습)

전체 시스템은 아래와 같은 흐름으로 연결됩니다.

(1) Main Node (Master): i.MX8MP PEVK

• i.MX8MP의 SAI(I2S) 핀들을 첫 번째 AD2428WD1BZ의 I2S 핀에 연결합니다.

• 이때 첫 번째 AD2428이 Master가 되어 전체 버스의 클록과 전원을 관리하게 설정합니다.

(2) Bus Cable:

• 두 개의 AD2428WD1BZ 보드 사이에 있는 DuraClik(2핀) 커넥터를 한 쌍의 꼬임선(UTP 케이블)으로 연결합니다. 이 선 하나로 오디오, 제어 신호(I2C), 전원이 다 갑니다.

(3) Sub Node (Slave): EV-21569 EZ-KIT

• 두 번째 AD2428WD1BZ의 I2S 핀들을 EV-21569의 DAI 핀에 연결합니다.

• 이 노드는 Master로부터 클록을 받아 동작합니다.

1.3 "그럼 너무 복잡하고 비싼 거 아냐?"

사실 이 방식이 어려운 이유는 평범한 개발 보드들을 억지로 연결하려다 보니 생기는 문제입니다.

• 원래 의도된 방식: ADI에서 나오는 ADZS-A2B-EXPENDER 같은 확장 카드를 EV-21569에 꽂으면, 그 카드 안에 이미 AD2428 칩과 회로가 들어 있습니다.

• 현재 상황: 지금은 범용 A2B 평가 보드(AD2428WD1BZ)를 가지고 계시기 때문에, 마치 조립 PC를 만들 듯이 와이어로 하나하나 노드를 구성해 주셔야 하는 상황입니다.

1.4 해결을 위한 제언

만약 단순히 i.MX8MP와 EV-21569 간에 오디오를 주고받는 것이 목적이고, 기술 자체를 테스트하려는 게 아니라면 를 빼고 직접 I2S로 연결하는 것이 훨씬 쉽습니다.

직접 연결: i.MX8MP SAI ↔ EV-21569 DAI (점퍼 와이어 4~5가닥으로 끝)
A2B 연결: AD2428 보드 2개 + I2C 설정(SigmaStudio) + 전원 설계 (매우 복잡)

를 반드시 써야 하는 상황(예: 차량용 오디오 네트워크 구현 등)인가요? 그렇다면 AD2428 보드는 최소 2개가 있어야 통신이 성립됩니다. 한 개만 있으시다면 추가 구매 혹은 다른 구성 방법을 고민해봐야 합니다.

빅데이터 분석기사와 AI

Jay.P Morgan — Mon, 11 May 2026 12:07:33 +0900

1. 빅데이터 분석기사 개요

빅데이터 분석기사는 국가기술자격법에 따라 시행되는 국가기술자격으로, 방대한 양의 데이터에서 가치를 추출하고 분석하는 능력을 검증하는 시험입니다. 데이터 수집, 저장, 처리부터 시각화 및 모델링까지 데이터 분석의 전 과정을 아우르는 전문가를 양성하기 위해 도입되었습니다.

1. 주요 수행 직무

이 자격을 취득하면 데이터 사이언티스트나 데이터 분석가로서 다음과 같은 핵심 역할을 수행할 수 있습니다.

• 데이터 수집 및 전처리: 정형/비정형 데이터를 수집하고, 분석에 적합하게 데이터를 정제 및 가공합니다.

• 데이터 탐색 및 모형 구축: 통계 기법과 머신러닝 알고리즘을 활용해 데이터를 분석하고 예측 모델을 만듭니다.

• 결과 해석 및 시각화: 분석 결과를 비즈니스 언어로 해석하고 시각화 도구를 통해 효과적으로 전달합니다.

1.2 시험 과목 및 방법

시험은 필기와 실기로 나뉘어 진행됩니다.

■ 필기 시험 (객관식)

필기는 총 4개 과목으로 구성되며, 각 과목당 20문항씩 출제됩니다.

1. 빅데이터 분석 기획: 분석 방안 수립, 데이터 수집 및 저장 계획.

2. 빅데이터 탐색: 데이터 전처리, 데이터 탐색, 통계 기법.

3. 빅데이터 모델링: 분석 모형 설계, 분석 기법 적용(머신러닝 등).

4. 빅데이터 결과 해석: 모형 평가 및 개선, 분석 결과 시각화.

합격 기준: 전 과목 평균 60점 이상 (단, 과목당 40점 미만 시 과락)

■ 실기 시험 (작업형)

실기 시험은 실제 클라우드 환경에서 코딩을 통해 데이터를 분석하는 능력을 평가합니다. Python 또는 R 중 하나를 선택하여 응시할 수 있습니다.

• 작업형 제1유형: 데이터 전처리 및 간단한 통계값 산출.

• 작업형 제2유형: 분류(Classification) 또는 회귀(Regression) 모델링 및 결과 도출.

• 작업형 제3유형: 가설 검정 등 통계적 분석 역량 평가.

합격 기준: 100점 만점 기준 60점 이상

1.3 응시 자격 및 가치

국가기술자격인 만큼 일정한 요건을 갖춰야 응시할 수 있습니다.

• 학력: 4년제 대학 졸업(예정)자 또는 전공 불문 학위 취득자.

• 경력: 기사 수준의 실무 경력 4년 이상 보유자.

취득 시 장점: 데이터 기반 의사결정이 중요해진 현대 비즈니스 환경에서 IT 기업, 금융권, 제조, 공공기관 등 다양한 산업군으로의 취업 및 이직 시 강력한 증빙 자료로 활용됩니다. 특히 공공기관 채용이나 승진 시 가산점을 받을 수 있는 공식적인 지표가 됩니다.

1.4 학습 팁

필기: 통계학의 기본 개념(가설 검정, 회귀 분석 등)과 머신러닝 알고리즘의 원리를 이해하는 것이 중요합니다.
실기: 특정 라이브러리(Pandas, Scikit-learn 등)를 활용해 데이터를 능숙하게 다루는 연습이 필수입니다. 특히 시험 환경이 평소 사용하는 IDE와 다를 수 있으므로 미리 체험 환경을 익혀두는 것이 좋습니다.

데이터 분석 역량을 증명하고 전문성을 키우고 싶으시다면 도전해 볼 만한 가치가 충분한 자격증입니다.

2. 빅데이터 분석기사와 인공지능(AI) 대학원

빅데이터 분석기사 자격증 취득 과정에서 배우는 내용은 인공지능(AI) 대학원 진학 및 연구를 위한 기초 체력을 기르는 데 상당히 도움이 됩니다. 다만, 자격증 취득 그 자체가 합격의 '치트키'가 되기보다는, 그 과정을 통해 얻는 기초 지식의 체계화에 의미를 두는 것이 좋습니다.

구체적으로 어떤 부분에서 도움이 되는지 정리해 드릴게요.

2.1 통계적 기초와 데이터 리터러시 (필기 과목 관련)

AI 대학원의 핵심은 결국 수학과 통계입니다. 빅데이터 분석기사 필기 과목에는 가설 검정, 회귀 분석, 확률 분포 등 기초 통계학이 비중 있게 포함되어 있습니다.

• 이점: 대학원 면접(구술 고사)에서 기초 통계 지식을 묻는 경우가 많은데, 자격증 공부를 통해 이를 체계적으로 정리할 수 있습니다.

• 연계성: 딥러닝 모델의 손실 함수나 최적화 원리를 이해하기 위한 수치적 감각을 익히는 데 밑거름이 됩니다.

2.2 머신러닝 워크플로우의 이해

시험의 '빅데이터 모델링' 과목은 데이터 전처리부터 모델 선택, 학습, 평가까지의 전체 파이프라인을 다룹니다.

• 이점: 단순히 코드만 복사하는 것이 아니라, '왜 이 시점에서 스케일링을 해야 하는지', '왜 교차 검증(Cross-Validation)이 필요한지' 등의 방법론을 익히게 됩니다.

• 실무적 도움: 대학원 연구 시 데이터를 처음 마주했을 때 분석의 방향성을 잡는 훈련이 됩니다.

2.3 Python/R 활용 능력 (실기 작업형 관련)

실기 시험은 Pandas, Scikit-learn 같은 핵심 라이브러리를 직접 다루어야 합니다.

• 이점: 데이터 프레임을 자유자재로 핸들링하는 능력은 AI 연구의 기본 중의 기본입니다.

• 현실적 조언: 대학원에서는 자격증 수준보다 훨씬 복잡하고 방대한 데이터를 다루지만, '작업형'을 통과할 수준의 코딩 실력은 연구를 시작하기 위한 최소한의 도구가 됩니다.

⚠️ 주의할 점 (현실적인 조언)

(1) 연구 역량 vs. 자격증: AI 대학원은 새로운 알고리즘을 제안하거나 문제를 해결하는 '연구 역량'을 중시합니다. 자격증은 "이 친구가 기초는 되어 있구나" 정도의 인상을 줄 뿐, 논문 실적이나 프로젝트 경험을 대체할 수는 없습니다.

(2) 수학적 깊이의 차이: 빅데이터 분석기사는 계산 위주라면, 대학원은 수식의 증명과 유도 과정을 중요하게 봅니다. 자격증 공부와 병행하여 선형대수학, 미적분학을 따로 깊게 파는 것이 반드시 필요합니다.

결론

"도움은 확실히 되지만, 그것만으로는 부족하다"고 말씀드릴 수 있습니다.

• 비전공자/입문자라면: 전체적인 AI/데이터 분석의 숲을 보는 용도로 강력 추천합니다.

• 전공자라면: 이미 아는 내용을 복습하는 정도일 수 있으므로, 자격증 취득에 너무 많은 시간을 쏟기보다는 관심 있는 분야의 논문을 읽거나 관련 프로젝트(Kaggle 등)를 병행하는 것을 권장합니다.

I2S (Inter-IC Sound)

Jay.P Morgan — Fri, 8 May 2026 11:21:24 +0900

◈ I2S (Inter-IC Sound)

I2S(Inter-IC Sound)는 디지털 오디오 장치 간에 데이터를 전송하기 위해 설계된 직렬 인터페이스 표준입니다. 필립스에서 제정했으며, 주로 MCU, DSP, 오디오 코덱, DAC/ADC 사이에서 무손실 오디오 데이터를 주고받을 때 사용하는 버스입니다.

I2S의 핵심은 데이터(Data)와 클록(Clock)을 분리하여 전송함으로써, 신호의 시간적 오차인 지터(Jitter)를 최소화한다는 점입니다.

1. I2S의 3대 핵심 신호라인

I2S는 최소 3개의 선으로 구성됩니다.

• SCK (Serial Clock): 비트 클록(BCLK)이라고도 하며, 데이터의 각 비트가 전송되는 타이밍을 결정합니다(동기식 통신에 사용).

• WS (Word Select): 좌/우 채널을 구분하는 신호입니다. (FS-Frame Select, LRCK라고도 부름)

- Low (0)일 때는 왼쪽 채널, High (1)일 때는 오른쪽 채널 데이터를 전송하는 것이 표준입니다.

- 좌우 채널은 일정한 주기로 반복이 되기 때문에 클럭으로 표기하기도 합니다.

• SD (Serial Data): 실제 오디오 데이터가 전송되는 라인입니다. (SDATA, SDINT, SDOUT으로 표시)

- 2의 보수(2's complement) 형태의 MSB부터 순차적으로 전송됩니다.

네 번째 라인, 마스터 클럭

I2S규격에는 포함되어 있지 않지만, 실제 제품에서 흔히 사용되는 네번째 라인이 있습니다. 마스터 클럭이라고 불리는 신호선으로 좌우 채널 선택 클럭(LRCLK)의 256배에 해당하는 클럭을 사용합니다. 오디오 집적 회로는 이 신호에 동기화하여 작동합니다.

원래 IC들은 내부에 OSC를 갖고 있는데, 별도로 외부의 클럭을 사용하는 것은 전송되는 데이터가 오디오라는 특수성 때문입니다. 오디오 데이터는 끊김이 없이 일정한 속도로 흘러 가야 하며, 만약 그렇지 못하면 스피커를 통해서 재생되는 중, 소리가 끊기거나 튀는 소리 등, 비정상적인 소리가 발생할 수 있기 때문입니다.

이러한 현상을 방지하기 위해서 시스템 내부의 모든 부품이 일사 분란하게 동작하여야 하며, 전투선의 북소리와 같은 역할을 마스터 클럭이 담당하게 된다.

2. 주요 동작 특성

• 마스터와 슬레이브: 통신을 제어하는 장치(주로 MCU나 DSP)가 클록(SCK, WS)을 생성하는 마스터가 되고, 데이터를 받는 쪽(DAC 등)이 슬레이브가 됩니다.

• 데이터 정렬 (Alignment): 표준 I2S 방식에서는 WS 신호가 변한 뒤 한 클록 뒤에 실제 데이터 비트가 시작됩니다. (이 외에도 Left-Justified, Right-Justified 등의 변형 포맷이 있습니다.)

• 동기화: 클록이 데이터와 별도로 존재하기 때문에 송수신 장치 간에 별도의 복잡한 동기화 과정 없이도 정확한 오디오 재생이 가능합니다.

3. I2S

I2S 기술의 세부사항

(1) 네트워크 구성

I2S는 버스 구조를 갖기 때문에 여러 대의 장치를 연결할 수 있다. 오디오 신호를 전송하는 기기(트랜스미터, Transmitter)와 오디오 신호를 수신하는 기기(리시버, Receiver)외에 마스터 클럭을 제공하는 기기(컨트롤러, Controller)가 연결될 수 있고, 또는 오디오 신호를 외부로부터 받아들일 수 있는 마이크 장치가 버스에 연결될 수 있다. 일반적으로 트랜스미터는 CPU, 혹은 마이크로 프로세서에 해당하고, 리시버는 디지털 신호를 아날로그 신호로 변환하여 스피커로 보내 주는 오디오 장치에 해당한다.

마스터 클럭을 제공하는 컨트롤러는 별도로 존재할 수도 있고, 트랜스미터나 리시버가 그 역할을 겸할 수도 있다. 이 경우에는 네트워크가 일대일 구성을 이루게 된다.

[그림 2] I2S 네트워크 구성

(2) 버전과 데이터의 전송 속도

일반적인 데이터를 전송하는 UART, I2C, SPI와 달리 오디오 데이터를 전송하는 I2S는 전송하는 데이터가 어떻게 생성되었는지에 따라서 데이터의 전송 속도가 정해진다. I2S는 디지털 오디오 데이터를 전송하는 커넥티비티이므로 디지털 오디오 데이터가 어떠한 특성을 갖느냐가 중요하다. 예를 들어 디지털 오디오 데이터가 고음질이라면, 초당 전송해야 하는 데이터 양을 많아 질 것이고, 그렇다면 데이터의 전송 속도도 올라가야 한다. 반면, 저음질의 오디오 데이터라면, 초당 전송해야 하는 데이터 양은 적을 것이며, 그렇다면 데이터의 전송 속도는 낮아질 것이다. 이러한 현상은 데이터의 전송과 스피커를 통한 출력이 동기화되어야 하기 때문에 발생한다. 아무리 빨리 데이터를 보낼 수 있다고 하더라도 스피커로 출력되는 데이터의 양을 이미 정해져 있기 때문이다. 반면, 고음질의 데이터의 경우에는 한번에 스피커로 출력할 수 있는 데이터의 양이 많다는 것을 의미하는데, 만약 충분한 커넥티비티가 데이터 전송 속도를 갖지 못한다면, 스피커에서는 계속해서 음이 끊기는 현상이 나타나게 될 것이다.

구체적으로 데이터의 전송 속도를 결정짓는 디지털 오디오의 특성은 다음과 같은 두 가지 요소가 중요한데, 첫째는 샘플링 레이트(sampling rate)이고, 둘째는 비트 깊이(bit depth)이다.

I2S는 오디오 신호를 전송하는 것이므로, 스피커를 통해서 소리가 출력되는 속도와 동일한 속도로 데이터의 전송이 이루어져야 한다. 더 빨라도 안 되고, 더 늦어도 안된다. 마스터 클럭을 통해서 데이터의 전송 속도와 오디오 집적 회로의 동작 클럭을 일치시키는 것도 이러한 이유 때문이다.

먼저, CD 의 음원을 전송하는 경우이다. 샘플링 레이트가 44.1kHz 이므로, 초당 44100번의 샘플링이 있었으며, 샘플링된 신호는 16비트로 양자화되었으므로 1초에 전송해야 할 데이터는 44100 x 16 비트 = 705,600 비트이다. 이것은 모노(mono)인 경우이다. 만약 스테레오의 경우라면 왼쪽과 오른쪽 마이크를 통해서 샘플링된 신호가 각각 존재하므로, 1초에 전송해야 할 데이터는 모노의 2배에 해당하므로 44100 x 16비트 x 2 채널 = 1,411,200 비트가 된다. 즉, CD음원을 전송하는 경우 I2S의 데이터 전송 속도는 1.411 Mbits/s가 된다. 이런 식으로 전송하는 오디오 음원의 제작 방법에 따라서 I2S의 데이터 전송 속도는 달라지게 된다.

기술의 동작

(1) 데이터의 전송

데이터의 전송을 위해서 세 개의 라인을 통해서 동기화된 출력이 필요하다. 첫째는 클럭 신호를 통해서, 오디오 데이터의 송신기와 수신기가 데이터를 주고 받기 위한 동기화를 하게 된다. 클럭 신호는 I2S 버스 시스템에 연결되어 있는 기기 중에서 한 곳에서 생성이 된다. 앞에서 설명한 것과 같이 클럭을 생성하는 장치를 마스터라고 한다.

클럭은 32KHz, 44.1KHz, 48KHz 또는 이들의 배수에 해당하는 값을 사용한다. 이유는 이미 앞에서 설명한 것과 같이 전송되는 데이터가 오디오이므로, 스피커를 통해서 출력하는 속도와 같아야 한다. 32KHz, 44.1KHz, 48KHz는 일반적으로 디지털 오디오 음원에 사용되는 샘플링 레이트이다. CD 음원을 사용하는 경우라면, 음원의 샘플링 레이트가 44.1KHz 이고, 16비트로 구성되며, 왼쪽 스피커/오른쪽 스피커(L/R)신호로 구성이 되므로, 사용되는 클럭은 44.1KHz x 16 비트 x 2 채널= 1.4112MHz이다.

둘째는 오디오가 스테레오의 경우라면, 좌우 채널 선택을 해주어야 한다. 즉, 현재 전송하고자 하는 오디오 신호가 왼쪽 채널인데, 오른쪽 채널인지를 리시버에게 알려주어야 한다. 그래야만 리시버는 자신에게 연결되어 있는 2개의 스피커 중 올바른 쪽으로 소리를 출력할 수 있다. 구체적으로 트랜스미터는 좌우 채널 선택 클럭 신호를 low신호로 바꾸고, 왼쪽 채널 신호를 전송한다. 그 다음 좌우 채널 선택 클럭 신호를 high신호로 바꾸고 오른쪽 채널 신호를 전송한다. 좌우 채널 선택은 일정한 주기로 반복이 된다.

셋째는 오디오 데이터를 전송한다. 오디오 데이터의 길이는 앞에서 살펴 본 비트 깊이(bit depth)에 따라 다르다. 데이터의 길이는 28비트까지 조정이 가능하다. 아래의 그림은 16비트 길이의 경우와 24비트 길이의 경우를 예시하고 있다.

[그림 3] I2S의 데이터 전송 타이밍

(2) 데이터 프레임

I2S는 오디오 데이터의 전송이 목적이기 때문에 데이터 프레임이란 다름 아닌 오디오 데이터를 담기 위한 포맷이며, 왼쪽과 오른쪽 채널의 구분이 있으나, 데이터의 포맷은 동일하다.

기술의 구현

(1) 안드로이드에서의 I2S

아래는 스마트 폰을 비롯하여 안드로이드가 탑재되는 기기에서 사용되는 I2S 버스 시스템의 일반적인 블록도이다. 전화 통화를 지원하기 위해서 기본적으로 마이크와 스피커가 탑재되어 있고, 마이크는 아날로그 신호를 디지털 신호로 변환하는 작업을 맡고, 스피커는 DAC(Digital Analog Converter)를 통해서 디지털 신호를 아날로그 신호로 변환한다.

[그림 4] 안드로이드에서의 I2S 연결

아래의 소스 코드는 안드로이드에서 I2S 통신을 하기 위한 환경 설정 부분이다.

private static final AudioFormat AUDIO_FORMAT_STEREO =

new AudioFormat.Builder()

.setChannelMask(AudioFormat.CHANNEL_IN_STEREO) // 2 channels

.setEncoding(AudioFormat.ENCODING_PCM_16BIT) // 16-bit samples

.setSampleRate(44100) // 44.1kHz

.build();

(2) TDM

I2S는 두 채널의 오디오 신호, 즉 왼쪽 스피커를 위한 채널과 오른쪽 스피커를 위한 채널를 전송하기 위한 규격이다. 그러나, 현실에서는 훨씬 많은 채널을 전송해야 할 필요가 있다. 서라운드 효과를 위해서 기본적으로 5.1채널이 요구되며, 보다 실감나는 효과를 위해서 7.1 채널도 사용이 된다. 이들은 왼쪽 스피커, 오른쪽 스피커 이외에도 후방의 좌우에 스피커를 각각 배치하며, 전방의 좌우 스피커에 사이에 센터 스피커를 배치한다. 그리고, 서브 우퍼가 연결이 된다. 이렇게 설치되어 있는 모든 스피커들에게 동일한 타이밍으로 오디오 신호를 전송해야만 올바른 소리를 들을 수 있다.

이 문제를 해결하기 위해서 I2S규격과 유사한 방식을 사용하는데, 이러한 방식을 TDM(Time Division Multiplexed)라고 한다. 이름에서도 짐작할 수 있듯이, 하나의 물리 채널을 이용하여 여러 개의 오디오 채널을 전송하기 위해, 각각의 오디오 채널에게 일정한 간격으로 시간을 할당하는 방식이다. I2S도 좌우 채널이 일정한 간격으로 각자의 오디오 신호를 전송하므로, TDM방식이라고 볼 수 있다. 다만, I2S는 단 2개의 오디오 채널만 사용되므로 5.1채널의 6채널보다 시간적으로 여유롭게 물리 채널을 사용할 수 있다.

TDM은 표준규격이 존재하지 않는다. 따라서 제조업체에 따라서 다양한 형태로 구현이 된다. 그러나, 기본적인 동작 방식은 거의 동일하다. I2S와 같이 데이터 전송을 위한 연결 라인, 동기 신호를 보내는 클럭 라인, 그리고, 프레임 동기화 신호를 전송하는 라인으로 구성이 된다.

4. I2S vs. 다른 인터페이스

• I2C/SPI와의 차이: I2C나 SPI는 일반적인 데이터를 주고받는 데 최적화되어 있지만, I2S는 실시간 오디오 스트리밍에 최적화되어 오디오 샘플링 레이트에 맞춘 정밀한 타이밍 제어가 가능합니다.

I2C와 I2S

• 연결

- I2C는 독자적으로 사용 가능

- I2S는 환경 설정을 해 줄 별도의 커넥비티비가 필요하고, 일반적으로 I2C가 그 역할을 담당

- 따라서, 일반적으로 오디오 데이터를 전송하는 I2S와 일반 데이터를 전송하는 I2C가 쌍을 이루어서 제품에서 사용

• 마스터 정의

- I2C에서는 데이터 전송을 시작할 수 있으면 마스터라고 부르지만,

- I2S에서는 클럭을 내보는 역할을 담당하는 기기를 마스터라고 부른다.

- I2S에서는 슬레이브라는 개념은 없으며, 데이터를 보내는 트랜스미터(Transmitter)와 데이터를 받는 리시버(receiver)가 있다.

• Duflex

- I2C는 데이터가 양방향으로 이동할 수 있는 반이중모드가 가능하지만, I2S는 단방향 통신만 가능하다.

PCM/TDM

I2S는 기본적으로 2채널(스테레오)을 지원합니다. 만약 8채널 이상의 다채널 오디오가 필요하다면 I2S를 확장한 TDM(Time Division Multiplexing) 방식을 사용하게 됩니다.

5. 하드웨어 설계 시 고려사항

실제 임베디드 시스템이나 하드웨어를 설계할 때 I2S와 관련하여 자주 언급되는 추가 신호가 있습니다.

• MCLK (Master Clock): I2S 표준 자체에는 포함되지 않으나, 오디오 코덱이나 DAC가 내부 연산을 위해 I2S 클록보다 훨씬 빠른(예: 256 x fs) 시스템 클록을 요구할 때 사용됩니다.

• 신호 무결성: 고속 디지털 신호이므로 라인 길이가 길어지면 노이즈나 반사가 발생할 수 있어, 보통 수 cm 이내의 짧은 거리에서 연결하거나 적절한 터미네이션 저항을 배치합니다.

I2S는 오늘날 블루투스 모듈, 오디오 앰프 설계, 하이파이(Hi-Fi) 오디오 시스템 등 디지털 음향이 들어가는 거의 모든 분야에서 표준으로 사용되고 있습니다.

참고: https://blog.naver.com/ittalentdonation/221194850771

ADI - DAI와 NXP - SAI

Jay.P Morgan — Thu, 7 May 2026 22:13:24 +0900

◈ ADI - DAI와 NXP - SAI

Analog Devices(ADI)의 DAI와 NXP i.MX8M Plus의 SAI는 모두 디지털 오디오 데이터를 주고받기 위한 핵심 인터페이스이지만, 설계 철학과 유연성 면에서 뚜렷한 차이가 있습니다.

1.1 Analog Devices의 DAI (Digital Audio Interface)

ADI의 SHARC나 SigmaDSP 프로세서에서 주로 볼 수 있는 DAI는 단순한 포트를 넘어선 '신호 라우팅 매트릭스'에 가깝습니다.

• 구조적 특징: DAI는 내부적으로 SRU(Signal Routing Unit)와 연결되어 있습니다. 이는 물리적인 핀과 내부의 직렬 포트(SPORT), 정밀 클록 생성기(PCG), SRC(Sample Rate Converter) 등을 소프트웨어 설정만으로 자유롭게 연결할 수 있게 해줍니다.

• 유연성: 특정 핀을 입력으로 쓸지, 출력으로 쓸지, 혹은 클록 신호만 내보낼지를 매우 자유롭게 구성할 수 있습니다.

• 주요 기능:

- SPORT (Serial Port): 실제 데이터를 처리하는 유닛으로, I2S, TDM, Left-Justified 등 다양한 규격을 지원합니다.

- PCG (Precision Clock Generator): 외부 수정진동자 없이도 정밀한 오디오 마스터 클록을 생성하여 배분할 수 있습니다.

• 장점: 복잡한 오디오 시스템(예: 수십 채널의 입출력이 필요한 카 오디오)에서 하드웨어 변경 없이 내부 라우팅만으로 신호 흐름을 바꿀 수 있습니다.

1.2 NXP i.MX8M Plus의 SAI (Synchronous Audio Interface)

i.MX8M Plus에 탑재된 SAI는 범용 애플리케이션 프로세서(AP)에서 표준적으로 사용하는 '고성능 동기식 직렬 인터페이스'입니다.

• 구조적 특징: 송신(TX)과 수신(RX) 섹션이 독립적인 비트 클록(BCLK)과 프레임 동기 신호(SYNC)를 가질 수 있도록 설계되었습니다. i.MX8MP에는 보통 여러 개의 SAI 인스턴스(SAI1~SAI7)가 있어 다채널 확장이 용이합니다.

• 시스템 통합: SoC 내부의 SDMA(Smart DMA)와 긴밀하게 연결되어 있어, CPU 점유율을 최소화하면서 대용량 오디오 데이터를 메모리로 실어 나르는 데 최적화되어 있습니다.

• 주요 기능:

- 다양한 프로토콜: I2S, AC97, TDM, DSP 모드를 지원합니다.

- FIFO 지원: 각 SAI 모듈은 내부 FIFO를 가지고 있어 오디오 데이터의 언더런(Under-run)이나 오버런(Over-run)을 방지합니다.

• 장점: 리눅스(ALSA/ASoC 프레임워크) 환경에서 드라이버 지원이 매우 탄탄하며, 멀티미디어 OS 위에서 안정적인 스트리밍을 구현하기에 적합합니다.

1.3 주요 차이점 요약

구분	ADI DAI	i.MX8M Plus SAI
핵심 성격	프로그래머블 라우팅 매트릭스	독립적 송수신 직렬 인터페이스
제어 방식	SRU를 통한 핀-유닛 간 자유 매핑	고정된 핀 기능 기반의 설정
클록 관리	내장 PCG를 통한 매우 정밀한 제어	SoC 클록 트리에 의존 (PLL 설정 중심)
주요 용도	실시간 오디오 신호 처리 (ANC, DSP 등)	오디오 스트리밍 및 인포테인먼트 (IVI)

요약하자면: ADI의 DAI는 "어떤 신호든 어디로든 보낼 수 있는 유연한 오디오 스위치보드" 같은 느낌이라면, i.MX8MP의 SAI는 "정해진 통로를 통해 고속으로 오디오 데이터를 실어 나르는 효율적인 고속도로"라고 이해하시면 쉽습니다.

2. ADI DSP와 NXP HeadUnit의 Pin 매칭

DSP(SHARC)와 i.MX8M Plus(SAI) 간에 디지털 오디오를 전송하려면, 두 보드 간의 I2S 또는 TDM 인터페이스 핀을 서로 일치시켜 연결해야 합니다.

보통 한쪽을 Master(클록 생성), 다른 한쪽을 Slave(클록 수신)로 설정하여 동기화하는 것이 기본입니다.

2.1 하드웨어 핀 매핑 (I2S 기준)

두 보드 모두 확장 커넥터를 통해 관련 핀을 제공합니다. 아래 표는 일반적인 I2S 연결을 위한 핀 구성입니다.

신호 명칭	ADSP-21569 (DAI Pin)	i.MX8MP (SAI Pin)	설명
BCLK (Bit Clock)	DAI0_PINxx (예: PIN01)	SAIx_TXC / SAIx_RXC	데이터 비트 단위 클록
LRCLK (Frame Sync)	DAI0_PINxx (예: PIN02)	SAIx_TXFS / SAIx_RXFS	채널 구분 신호 (Left/Right)
SDATA_OUT	DAI0_PINxx (예: PIN03)	SAIx_RXD0 (i.MX8M 입력)	DSP → AP 데이터 전송
SDATA_IN	DAI0_PINxx (예: PIN04)	SAIx_TXD0 (i.MX8M 출력)	AP → DSP 데이터 전송
GND	Digital Ground	Digital Ground	공통 접지 (필수)

주의: ADI 보드의 경우 DAI 핀은 소프트웨어(SRU)로 설정하기 나름이므로, 사용 중인 예제 코드(LARK, CCES Framework 등)에서 어떤 DAI 핀을 SPORT로 할당했는지 먼저 확인해야 합니다.

2.2 구체적인 보드별 Con 위치

ADSP-21569 EV-21569-EZKIT

이 보드는 주로 Expansion Interface 3 (EI3) 또는 별도의 하위 커넥터를 통해 DAI 핀을 인출합니다.

• 주로 DAI0 (PIN 1~20)이 오디오 입출력에 사용됩니다.

• 매뉴얼의 'Connector Pinout' 섹션에서 사용하려는 SPORT(예: SPORT0)가 어느 PIN 번호에 매핑되어 있는지 확인하십시오.

i.MX8M Plus EVK (PEVK)

주로 보드 우측의 40-pin Expansion Header (J14)를 사용합니다. Raspberry Pi 핀 배열과 유사하지만 SAI 기능이 할당되어 있습니다.

• SAI3 또는 SAI5가 주로 이 헤더에 할당됩니다.

• 예: SAI3_TXD(PIN 38), SAI3_TXFS(PIN 35), SAI3_TXC(PIN 12) 등을 사용합니다.

2.3 연결 시 핵심 체크리스트

(1) 전압 레벨 (V_IO):

• 두 보드 모두 3.3V LVCMOS를 사용하는지 반드시 확인하십시오. 만약 한쪽이 1.8V라면 레벨 시프터(Level Shifter)가 반드시 필요합니다.

(2) Master / Slave 설정:

• 일반적으로 시스템 안정성을 위해 ADSP-21569를 Master로 설정하고 정밀한 오디오 클록(BCLK, LRCLK)을 내보내면, i.MX8MP를 Slave로 설정하여 해당 클록에 맞춰 데이터를 받도록 구성하는 것이 좋습니다.

(3) MCLK (Master Clock) 전송 여부:

• 두 장치 간에 샘플링 레이트 동기화가 엄격해야 한다면, DSP의 MCLK를 i.MX8MP의 SAI_MCLK 핀으로 보내줘야 할 수도 있습니다. 하지만 단순 I2S 통신에서는 BCLK/LRCLK만으로도 충분한 경우가 많습니다.

(4) TDM 모드 사용 시:

• 8채널 이상을 전송한다면 TDM 모드를 써야 합니다. 이때는 Frame Sync 신호의 폭(Pulse vs 50% Duty) 설정을 두 보드에서 일치시켜야 소리가 깨지지 않습니다.

ONNX Tutorial

Jay.P Morgan — Fri, 1 May 2026 00:11:25 +0900

1. ONNX Runtime Inferencing: API Basics

이 튜토리얼에서는 각 언어 API를 사용하여 ONNX 런타임으로 기본적인 추론을 수행하는 방법을 보여줍니다. 더 많은 예제는 microsoft/onnxruntime-inference-examples에서 확인할 수 있습니다.

1.1 Python

Scikit-learn Logistic Regression

ONNX 런타임은 학습 프레임워크에 의존하지 않고 CPU 또는 GPU에서 고성능으로 머신 러닝 모델을 쉽게 실행할 수 있는 방법을 제공합니다. 머신 러닝 프레임워크는 일반적으로 예측보다는 배치 학습에 최적화되어 있지만, 애플리케이션, 웹사이트 및 서비스에서는 예측이 더 일반적인 시나리오입니다. ONNX 런타임을 사용하면 다음과 같은 작업을 수행할 수 있습니다.

(1) 원하는 프레임워크를 사용하여 모델을 학습합니다.

(2) 모델을 ONNX 형식으로 변환하거나 내보냅니다. 자세한 내용은 ONNX 튜토리얼을 참조하세요.

(3) ONNX 런타임을 사용하여 모델을 로드하고 실행합니다.

이 튜토리얼에서는 scikit-learn을 사용하여 파이프라인을 간략하게 구성하고, 이를 ONNX 형식으로 변환한 다음 첫 번째 예측을 실행합니다.

1단계: 선호하는 프레임워크를 사용하여 모델을 학습시키세요.

저희는 유명한 iris 데이터셋을 사용하겠습니다.

<<<

from sklearn.datasets import load_iris

from sklearn.model_selection import train_test_split

iris = load_iris()

X, y = iris.data, iris.target

X_train, X_test, y_train, y_test = train_test_split(X, y)

from sklearn.linear_model import LogisticRegression

clr = LogisticRegression()

clr.fit(X_train, y_train)

print(clr)

>>>

LogisticRegression()

2단계: 모델을 ONNX 형식으로 변환 또는 내보내기

ONNX는 머신러닝 모델을 설명하는 형식입니다. 모델을 구성하는 데 일반적으로 사용되는 연산자 집합을 정의합니다. 다른 모델 형식을 ONNX 형식으로 변환하는 도구가 있습니다. 여기서는 ONNXMLTools를 사용하겠습니다.

<<<

from skl2onnx import convert_sklearn

from skl2onnx.common.data_types import FloatTensorType

initial_type = [('float_input', FloatTensorType([None, 4]))]

onx = convert_sklearn(clr, initial_types=initial_type)

with open("logreg_iris.onnx", "wb") as f:

f.write(onx.SerializeToString())

>>>

3단계: ONNX 런타임을 사용하여 모델 로드 및 실행

이 머신러닝 모델의 예측값을 계산하기 위해 ONNX 런타임을 사용합니다.

<<<

import numpy

import onnxruntime as rt

sess = rt.InferenceSession(

"logreg_iris.onnx", providers=rt.get_available_providers())

input_name = sess.get_inputs()[0].name

pred_onx = sess.run(None, {input_name: X_test.astype(numpy.float32)})[0]

print(pred_onx)

>>>

[0 2 1 0 1 1 1 0 1 0 2 1 2 2 0 1 2 2 0 0 0 2 1 2 1 2 0 1 1 2 2 2 0 0 1 0 1

코드에서 특정 출력값을 얻으려면, 출력값의 이름을 목록에 지정하여 코드를 수정할 수 있습니다.

<<<

import numpy

import onnxruntime as rt

sess = rt.InferenceSession(

"logreg_iris.onnx", providers=rt.get_available_providers())

input_name = sess.get_inputs()[0].name

label_name = sess.get_outputs()[0].name

pred_onx = sess.run(

[label_name], {input_name: X_test.astype(numpy.float32)})[0]

print(pred_onx)

>>>

[0 2 1 0 1 1 1 0 1 0 2 1 2 2 0 1 2 2 0 0 0 2 1 2 1 2 0 1 1 2 2 2 0 0 1 0 1

1.2 Image recognition (Resnet50)

Image recognition (Resnet50)

1.3 C/C++ examples

C/C++ examples

1.4 C#

1.5 Java

Number recognition (MNIST)

1.6 JavaScript

ONNX Runtime JavaScript examples

2. Accelation PyTorch

2.1 PyTorch Inference

PyTorch 모델 추론

PyTorch에 대해 알아보고 PyTorch 모델을 사용한 추론 방법을 살펴보겠습니다.

PyTorch는 사용하기 쉽고 유연한 API, 특히 자연어 처리(NLP) 영역에서 제공되는 풍부한 기성 모델, 그리고 도메인별 라이브러리를 통해 딥러닝 분야를 선도하고 있습니다.

PyTorch로 구축된 모델을 사용하려는 개발자와 애플리케이션 생태계가 점점 확대되고 있으며, 이 글에서는 PyTorch 모델 추론에 대한 간략한 개요를 제공합니다. PyTorch 모델을 추론하는 방법은 여러 가지가 있으며, 아래에 나열되어 있습니다.

이 글은 PyTorch 모델을 학습시키는 방법이 아닌, PyTorch 모델을 사용한 추론 방법에 대한 정보를 찾는 독자를 대상으로 합니다.

PyTorch 개요

PyTorch의 핵심은 nn.Module 클래스입니다. 이 클래스는 전체 딥러닝 모델 또는 단일 레이어를 나타냅니다. 모듈은 조합하거나 확장하여 모델을 구축할 수 있습니다. 자체 모듈을 작성하려면 모델 입력과 학습된 가중치를 기반으로 출력을 계산하는 순방향 함수를 구현해야 합니다. 자체 PyTorch 모델을 작성하는 경우, 모델을 학습시키는 과정도 함께 진행해야 합니다. 또는 PyTorch 자체 또는 HuggingFace와 같은 다른 라이브러리에서 제공하는 사전 학습된 모델을 사용할 수도 있습니다.

PyTorch를 사용하여 이미지 처리 모델을 코딩하는 방법은 다음과 같습니다.

import torch

import torch.nn as nn

import torchvision.transforms as T

from torchvision.models import resnet18, ResNet18_Weights

class Predictor(nn.Module):

def __init__(self):

super().__init__()

weights = ResNet18_Weights.DEFAULT

self.resnet18 = resnet18(weights=weights, progress=False).eval()

self.transforms = weights.transforms()

def forward(self, x: torch.Tensor) -> torch.Tensor:

with torch.no_grad():

x = self.transforms(x)

y_pred = self.resnet18(x)

return y_pred.argmax(dim=1)

HuggingFace 라이브러리를 사용하여 언어 모델을 생성하려면 다음 단계를 따르세요.

model_name = "bert-large-uncased-whole-word-masking-finetuned-squad"

tokenizer = transformers.BertTokenizer.from_pretrained(model_name)

model = transformers.BertForQuestionAnswering.from_pretrained(model_name)

학습된 모델을 생성하거나 가져온 후, 추론을 수행하기 위해 어떻게 실행할까요? 아래에서는 PyTorch에서 추론을 수행하는 데 사용할 수 있는 몇 가지 접근 방식을 설명합니다.

추론 옵션

PyTorch 네이티브를 사용한 추론

성능이나 크기에 민감하지 않고 Python 실행 파일과 라이브러리가 포함된 환경에서 실행하는 경우, 애플리케이션을 PyTorch 네이티브로 실행할 수 있습니다.

학습된 모델이 준비되면, 데이터 과학 팀에서 추론을 위해 모델을 저장하고 불러오는 데 사용할 수 있는 두 가지 방법이 있습니다.
(1) 전체 모델 저장 및 불러오기

# Save the entire model to PATH

torch.save(model, PATH)

# Load the model from PATH and set eval mode for inference

model = torch.load(PATH)

model.eval()

(2) 모델의 매개변수를 저장하고, 모델을 다시 선언한 다음, 매개변수를 불러옵니다.

# Save the model parameters

torch.save(model.state_dict(), PATH)

# Redeclare the model and load the saved parameters

model = TheModel(...)

model.load_state_dict(torch.load(PATH))

model.eval()

어떤 방법을 사용할지는 구성에 따라 다릅니다. 전체 모델을 저장하고 불러오는 방식은 모델을 다시 선언하거나 모델 코드 자체에 접근할 필요가 없다는 장점이 있습니다. 하지만 저장 환경과 불러오는 환경의 클래스, 메서드, 매개변수가 일치해야 한다는 단점이 있습니다(이러한 요소들은 직접 직렬화 및 역직렬화되기 때문입니다).

모델의 학습된 매개변수(상태 사전, state_dict)를 저장하는 방식은 원본 모델 코드에 접근할 수 있는 한 첫 번째 방식보다 유연합니다.

모델 추론에 네이티브 PyTorch를 사용하지 않으려는 주된 이유는 두 가지입니다. 첫째, Python 런타임과 PyTorch 라이브러리 및 관련 종속성이 포함된 환경에서 실행해야 합니다. 이러한 파일들의 용량은 수 기가바이트에 달합니다. 모바일, 웹 브라우저 또는 특수 하드웨어와 같은 환경에서 실행하려는 경우 네이티브 PyTorch를 사용한 PyTorch 추론은 제대로 작동하지 않습니다. 둘째, 성능 문제입니다. PyTorch 모델은 기본 설정 상태에서는 애플리케이션에 필요한 성능을 제공하지 못할 수 있습니다.

TorchScript를 사용한 추론

PyTorch 또는 다른 Python 라이브러리를 설치할 수 없는 제약이 있는 환경에서 실행하는 경우, PyTorch 모델을 TorchScript로 변환하여 추론을 수행하는 옵션이 있습니다. TorchScript는 Python의 하위 집합으로, Python이 아닌 환경에서도 로드하고 실행할 수 있는 직렬화된 모델을 생성할 수 있도록 합니다.

# Export to TorchScript

script = torch.jit.script(model, example)

# Save scripted model

script.save(PATH)

# Load scripted model

model = torch.jit.load(PATH)

model.eval()

#include <torch/script.h>

...

torch::jit::script::Module module;

try {

// Deserialize the ScriptModule

module = torch::jit::load(PATH);

}

catch (const c10::Error& e) {

...

}

...

TorchScript 방식을 사용하면 PyTorch 모델에 대한 추론을 수행하기 위해 환경에 Python 런타임이 필요하지는 않지만, libtorch 바이너리를 설치해야 합니다. 그런데 이 바이너리의 용량이 환경에 비해 너무 클 수 있습니다. 또한 애플리케이션에 필요한 성능을 얻지 못할 수도 있습니다.

ONNXRuntime을 사용한 추론

성능과 이식성이 가장 중요한 경우, ONNXRuntime을 사용하여 PyTorch 모델을 추론할 수 있습니다. ONNXRuntime을 사용하면 지연 시간과 메모리 사용량을 줄이고 처리량을 높일 수 있습니다. 또한 ONNXRuntime에서 제공하는 언어 바인딩 및 라이브러리를 사용하여 클라우드, 엣지, 웹 또는 모바일 환경에서 모델을 실행할 수 있습니다.

첫 번째 단계는 PyTorch ONNX 익스포터를 사용하여 PyTorch 모델을 ONNX 형식으로 내보내는 것입니다.

# Specify example data

example = ...

# Export model to ONNX format

torch.onnx.export(model, PATH, example)

ONNX 형식으로 내보낸 후에는 선택적으로 Netron 뷰어에서 모델을 확인하여 모델 그래프, 입력 및 출력 노드의 이름과 모양, 그리고 가변 크기의 입력 및 출력을 가진 노드(동적 축)를 이해할 수 있습니다.

그런 다음 원하는 환경에서 ONNX 모델을 실행할 수 있습니다. ONNXRuntime 엔진은 C++로 구현되었으며 C++, Python, C#, Java, Javascript, Julia 및 Ruby API를 제공합니다. ONNXRuntime은 Linux, Mac, Windows, iOS 및 Android에서 모델을 실행할 수 있습니다. 예를 들어, 다음 코드 스니펫은 C++ 추론 애플리케이션의 기본 구조를 보여줍니다.

// Allocate ONNXRuntime session

auto memory_info = Ort::MemoryInfo::CreateCpu(OrtDeviceAllocator, OrtMemTypeCPU);

Ort::Env env;

Ort::Session session{env, ORT_TSTR("model.onnx"), Ort::SessionOptions{nullptr}};

// Allocate model inputs: fill in shape and size

std::array<float, ...> input{};

std::array<int64_t, ...> input_shape{...};

Ort::Value input_tensor = Ort::Value::CreateTensor<float>(memory_info, input.data(), input.size(), input_shape.data(), input_shape.size());

const char* input_names[] = {...};

// Allocate model outputs: fill in shape and size

std::array<float, ...> output{};

std::array<int64_t, ...> output_shape{...};

Ort::Value output_tensor = Ort::Value::CreateTensor<float>(memory_info, output.data(), output.size(), output_shape.data(), output_shape.size());

const char* output_names[] = {...};

// Run the model

session_.Run(Ort::RunOptions{nullptr}, input_names, &input_tensor, 1, output_names, &output_tensor, 1);

ONNXRuntime은 기본적으로 ONNX 그래프에 일련의 최적화를 적용하여 가능한 경우 노드를 결합하고 상수 값을 분리(상수 폴딩)합니다. 또한 ONNXRuntime은 실행 공급자 인터페이스를 통해 CUDA, TensorRT, OpenVINO, CoreML, NNAPI 등 다양한 하드웨어 가속기와 통합되며, 대상 하드웨어 플랫폼에 따라 사용할 수 있는 가속기가 달라집니다.

ONNX 모델의 성능을 더욱 향상시키려면 양자화를 수행할 수 있습니다.

모바일이나 엣지 컴퓨팅과 같이 제약이 있는 환경에서 애플리케이션을 실행하는 경우, 애플리케이션에서 사용하는 모델 또는 모델 세트를 기반으로 크기를 줄인 런타임을 구축할 수 있습니다.

원하는 언어와 환경에서 시작하려면 Get started with ONNX Runtime를 참조하세요.

예제

Export model to ONNX

Accelerated inference with ONNXRuntime

RESNET-50

Accelerate RESNET-50 model on CPU, GPU, and OpenVINO

요구 사항

모든 빌드에는 en_US.UTF-8 로케일이 포함된 영어 언어 패키지가 필요합니다.

Linux에서는 locale-gen en_US.UTF-8 및 update-locale LANG=en_US.UTF-8 명령을 실행하여 language-pack-en 패키지를 설치하십시오.
Windows 빌드에는 Visual C++ 2019 런타임이 필요합니다. 최신 버전을 권장합니다.

CUDA 및 cuDNN

ONNX Runtime GPU 패키지를 사용하려면 CUDA와 cuDNN을 설치해야 합니다. 호환되는 CUDA 및 cuDNN 버전은 CUDA 실행 공급자 요구 사항을 참조하십시오.
zlib는 Linux용 cuDNN 9.x에서만 필요합니다(zlib는 cuDNN 9.x Windows 동적 라이브러리에 정적으로 링크됨). Linux 및 Windows용 cuDNN 8.x에서도 zlib가 필요합니다. Linux 또는 Windows에 zlib를 설치하려면 cuDNN 8.9 설치 가이드를 따르십시오.
Windows에서는 CUDA bin 및 cuDNN bin 디렉터리의 경로를 PATH 환경 변수에 추가해야 합니다. Linux에서는 CUDA lib64 및 cuDNN lib 디렉터리의 경로를 LD_LIBRARY_PATH 환경 변수에 추가해야 합니다.
onnxruntime-gpu 패키지의 경우, CUDA 또는 cuDNN을 수동으로 설치하지 않고도 PyTorch와 함께 사용할 수 있습니다. 자세한 내용은 PyTorch와의 호환성을 참조하십시오.

Python 설치

ONNX Runtime CPU 설치

2.2 Inference on multiple target

ONNX Runtime을 사용하여 다양한 하드웨어 환경에서 PyTorch 모델 추론하기

PyTorch 또는 ONNX 모델을 배포하고 성능과 하드웨어 유연성을 극대화하려는 개발자라면 ONNX 런타임을 활용하여 하드웨어 플랫폼에 최적화된 모델을 실행할 수 있습니다.

이 튜토리얼에서는 다음 내용을 학습합니다.

(1) 이미지 분류를 위한 PyTorch ResNet-50 모델 사용 방법

(2) ONNX 형식으로 변환하는 방법

(3) 동일한 애플리케이션 코드를 사용하여 모든 하드웨어 플랫폼에서 추론을 로드하고 실행하는 ONNX 런타임을 통해 기본 CPU, NVIDIA CUDA(GPU), Intel OpenVINO에 배포하는 방법

ONNX는 Microsoft, Meta, Amazon 및 기타 기술 기업들이 머신 러닝 모델을 표준화하고 다양한 유형의 하드웨어에 쉽게 배포할 수 있도록 개발한 오픈 소스 ML 모델 형식입니다. ONNX Runtime은 Microsoft에서 기여하고 유지 관리하며, PyTorch, TensorFlow 등의 프레임워크에서 ONNX 모델의 성능을 최적화합니다. ImageNet 데이터셋으로 학습된 ResNet-50 모델은 이미지 분류에 일반적으로 사용됩니다.

이 튜토리얼에서는 Microsoft Azure Machine Learning을 사용하여 OpenVINO 및 ONNX 런타임으로 CPU, GPU 및 Intel 하드웨어에서 ONNX 모델을 실행하는 방법을 보여줍니다.

설정

운영체제 필수 조건

환경에 curl이 설치되어 있어야 합니다.

장치 필수 조건(Device Prerequisites)

onnxruntime-gpu 라이브러리는 장치 또는 컴퓨팅 클러스터의 NVIDIA CUDA 가속기에 대한 액세스가 필요하지만, CPU 및 OpenVINO-CPU 데모는 CPU에서만 실행해도 작동합니다.

추론 필수 조건(Inference Prerequisites)

추론할 이미지가 있는지 확인하십시오. 이 튜토리얼에서는 Notebook 파일과 같은 디렉터리에 "cat.jpg" 이미지가 있습니다.

환경 필수 조건(Environment Prerequisites)

Azure Notebook 터미널 또는 AnaConda 프롬프트 창에서 다음 명령을 실행하여 CPU, GPU 및/또는 OpenVINO용 환경 3개를 생성합니다(차이점은 굵게 표시됨).

CPU

conda create -n cpu_env_demo python=3.8

conda activate cpu_env_demo

conda install -c anaconda ipykernel

conda install -c conda-forge ipywidgets

python -m ipykernel install --user --name=cpu_env_demo

jupyter notebook

GPU

conda create -n gpu_env_demo python=3.8

conda activate gpu_env_demo

conda install -c anaconda ipykernel

conda install -c conda-forge ipywidgets

python -m ipykernel install --user --name=gpu_env_demo

jupyter notebook

OpenVINO

conda create -n openvino_env_demo python=3.8

conda activate openvino_env_demo

conda install -c anaconda ipykernel

conda install -c conda-forge ipywidgets

python -m ipykernel install --user --name=openvino_env_demo

python -m pip install --upgrade pip

pip install openvino

라이브러리 요구 사항

첫 번째 코드 셀에서 다음 코드 조각을 사용하여 필요한 라이브러리를 설치하세요(차이점은 굵게 표시).

CPU + GPU

import sys

if sys.platform in ['linux', 'win32']: # Linux or Windows

!{sys.executable} -m pip install torch==1.9.0+cu111 torchvision==0.10.0+cu111 torchaudio===0.9.0 -f https://download.pytorch.org/whl/torch_stable.html

else: # Mac

print("PyTorch 1.9 MacOS Binaries do not support CUDA, install from source instead")

!{sys.executable} -m pip install onnxruntime-gpu onnx onnxconverter_common==1.8.1 pillow

OpenVINO

import sys

if sys.platform in ['linux', 'win32']: # Linux or Windows

!{sys.executable} -m pip install torch==1.9.0+cu111 torchvision==0.10.0+cu111 torchaudio===0.9.0 -f https://download.pytorch.org/whl/torch_stable.html

else: # Mac

print("PyTorch 1.9 MacOS Binaries do not support CUDA, install from source instead")

!{sys.executable} -m pip install onnxruntime-openvino onnx onnxconverter_common==1.8.1 pillow

import openvino.utils as utils

utils.add_openvino_libs_to_path()

ResNet-50 데모

환경 설정

모델을 가져오고 추론을 실행하는 데 필요한 라이브러리를 가져옵니다.

from torchvision import models, datasets, transforms as T

import torch

from PIL import Image

import numpy as np

사전 학습된 ResNet-50 모델을 ONNX로 로드 및 내보내기

PyTorch에서 사전 학습된 ResNet-50 모델을 다운로드하고 ONNX 형식으로 내보냅니다.

resnet50 = models.resnet50(pretrained=True)

# Download ImageNet labels

!curl -o imagenet_classes.txt https://raw.githubusercontent.com/pytorch/hub/master/imagenet_classes.txt

# Read the categories

with open("imagenet_classes.txt", "r") as f:

categories = [s.strip() for s in f.readlines()]

# Export the model to ONNX

image_height = 224

image_width = 224

x = torch.randn(1, 3, image_height, image_width, requires_grad=True)

torch_out = resnet50(x)

torch.onnx.export(resnet50, # model being run

x, # model input (or a tuple for multiple inputs)

"resnet50.onnx", # where to save the model (can be a file or file-like object)

export_params=True, # store the trained parameter weights inside the model file

opset_version=12, # the ONNX version to export the model to

do_constant_folding=True, # whether to execute constant folding for optimization

input_names = ['input'], # the model's input names

output_names = ['output']) # the model's output names

샘플 출력:

% Total % Received % Xferd Average Speed Time Time Time Current

Dload Upload Total Spent Left Speed

100 10472 100 10472 0 0 50581 0 --:--:-- --:--:-- --:--:-- 50834

추론을 위한 전처리 설정(Set up Pre-Processing for Inference )

모델을 사용하여 추론할 이미지(예: cat.jpg)에 대한 전처리를 생성합니다.

# Pre-processing for ResNet-50 Inferencing, from https://pytorch.org/hub/pytorch_vision_resnet/

resnet50.eval()

filename = 'cat.jpg' # change to your filename

input_image = Image.open(filename)

preprocess = T.Compose([

T.Resize(256),

T.CenterCrop(224),

T.ToTensor(),

T.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]),

])

input_tensor = preprocess(input_image)

input_batch = input_tensor.unsqueeze(0) # create a mini-batch as expected by the model

# move the input and model to GPU for speed if available

print("GPU Availability: ", torch.cuda.is_available())

if torch.cuda.is_available():

input_batch = input_batch.to('cuda')

resnet50.to('cuda')

샘플 출력:

GPU Availability: False

ONNX 런타임을 사용하여 ResNet-50 ONNX 모델 추론하기

환경에 맞는 실행 공급자를 선택하여 ONNX 런타임으로 모델을 추론합니다. CPU를 사용하는 환경이라면 CPUExecutionProvider의 주석을 해제하고, NVIDIA CUDA를 사용하는 환경이라면 CUDAExecutionProvider의 주석을 해제하고, OpenVINOExecutionProvider를 사용하는 환경이라면 OpenVINOExecutionProvider의 주석을 해제합니다. 이때 onnxruntime.InferenceSession의 나머지 코드는 주석 처리해야 합니다.

# Inference with ONNX Runtime

import onnxruntime

from onnx import numpy_helper

import time

session_fp32 = onnxruntime.InferenceSession("resnet50.onnx", providers=['CPUExecutionProvider'])

# session_fp32 = onnxruntime.InferenceSession("resnet50.onnx", providers=['CUDAExecutionProvider'])

# session_fp32 = onnxruntime.InferenceSession("resnet50.onnx", providers=['OpenVINOExecutionProvider'])

def softmax(x):

"""Compute softmax values for each sets of scores in x."""

e_x = np.exp(x - np.max(x))

return e_x / e_x.sum()

latency = []

def run_sample(session, image_file, categories, inputs):

start = time.time()

input_arr = inputs.cpu().detach().numpy()

ort_outputs = session.run([], {'input':input_arr})[0]

latency.append(time.time() - start)

output = ort_outputs.flatten()

output = softmax(output) # this is optional

top5_catid = np.argsort(-output)[:5]

for catid in top5_catid:

print(categories[catid], output[catid])

return ort_outputs

ort_output = run_sample(session_fp32, 'cat.jpg', categories, input_batch)

print("ONNX Runtime CPU/GPU/OpenVINO Inference time = {} ms".format(format(sum(latency) * 1000 / len(latency), '.2f')))

샘플 출력:

Egyptian cat 0.78605634

tabby 0.117310025

tiger cat 0.020089425

Siamese cat 0.011728076

plastic bag 0.0052174763

ONNX Runtime CPU Inference time = 32.34 ms

PyTorch와의 비교

PyTorch를 사용하여 ONNX 런타임의 CPU 및 GPU 정확도와 지연 시간을 벤치마킹해 보세요.

# Inference with PyTorch

latency = []

start = time.time()

with torch.no_grad():

torch_output = resnet50(input_batch)

latency.append(time.time() - start)

# Convert to numpy

torch_output_np = torch_output.cpu().detach().numpy()

# Print classification results

output = torch_output_np.flatten()

output = softmax(output)

top5_catid = np.argsort(-output)[:5]

for catid in top5_catid:

print(categories[catid], output[catid])

print("PyTorch CPU Inference time = {} ms".format(format(sum(latency) * 1000 / len(latency), '.2f')))

print("***** Verifying correctness *****")

for i in range(2):

print('PyTorch and ONNX Runtime output {} are close:'.format(i), np.allclose(ort_output, torch_output_np, rtol=1e-05, atol=1e-04))

샘플 출력:

Egyptian cat 0.78605634

tabby 0.117310025

tiger cat 0.020089425

Siamese cat 0.011728076

plastic bag 0.0052174763

PyTorch CPU Inference time = 34.56 ms

***** Verifying correctness *****

PyTorch and ONNX Runtime output 0 are close: True

PyTorch and ONNX Runtime output 1 are close: True

OpenVINO와의 비교

OpenVINO를 사용하여 ONNX 런타임과 OpenVINO의 정확도 및 지연 시간을 비교 평가합니다.

# Inference with OpenVINO

from openvino.runtime import Core

ie = Core()

onnx_model_path = "./resnet50.onnx"

model_onnx = ie.read_model(model=onnx_model_path)

compiled_model_onnx = ie.compile_model(model=model_onnx, device_name="CPU")

# inference

output_layer = next(iter(compiled_model_onnx.outputs))

latency = []

input_arr = input_batch.detach().numpy()

inputs = {'input':input_arr}

start = time.time()

request = compiled_model_onnx.create_infer_request()

output = request.infer(inputs=inputs)

outputs = request.get_output_tensor(output_layer.index).data

latency.append(time.time() - start)

print("OpenVINO CPU Inference time = {} ms".format(format(sum(latency) * 1000 / len(latency), '.2f')))

print("***** Verifying correctness *****")

for i in range(2):

print('OpenVINO and ONNX Runtime output {} are close:'.format(i), np.allclose(ort_output, outputs, rtol=1e-05, atol=1e-04))

샘플 출력:

Egyptian cat 0.7820879
tabby 0.113261245
tiger cat 0.020114701
Siamese cat 0.012514038
plastic bag 0.0056432663
OpenVINO CPU Inference time = 31.83 ms
***** Verifying correctness *****
PyTorch and ONNX Runtime output 0 are close: True
PyTorch and ONNX Runtime output 1 are close: True

Conclusion

결론

ONNX Runtime은 CPU, NVIDIA CUDA(GPU), Intel OpenVINO(모바일)에서 PyTorch 또는 ONNX 모델을 실행하는 효과적인 방법임을 입증했습니다. ONNX Runtime을 사용하면 실행 공급자(Execution Providers)에서 제공하는 더 다양한 하드웨어에 배포할 수 있습니다. ONNX Runtime Github repo에 참여하여 여러분의 의견을 들려주시면 감사하겠습니다.

비디오 데모

ResNet-50 배포 및 유연한 추론에 대한 자세한 설명과 단계별 가이드는 여기에서 비디오를 시청하세요.

1.3 Accelerate PyTorch Training

ORTModule Examples

Use ORTModule with HuggingFace Models

2. Accelating TensorFlow

Accelerate TensorFlow model inferencing

ONNX 런타임은 TensorFlow, TFLite 및 Keras 모델의 추론 시간을 단축할 수 있습니다.

Get Started

End to end: Run TensorFlow models in ONNX Runtime

Export model to ONNX

TensorFlow/Keras

These examples use the TensorFlow-ONNX converter, which supports TensorFlow 1, 2, Keras, and TFLite model formats.

TFLite

TFLite: Image classification (mobiledet)

3. Accelerate Hugging Face models

ONNX Runtime can accelerate training and inferencing popular Hugging Face NLP models.

1.1 Yocto Project 소개

Accelerate Hugging Face model inferencing

Additional resources

4. AzureML에서 ONNX 런타임을 사용하여 고성능 질의응답 모델 배포하기

이 튜토리얼에서는 HuggingFace의 BERT 모델을 ONNX로 변환하고, AzureML을 통해 ONNX 런타임과 함께 ONNX 모델을 배포하는 방법을 설명합니다.

다음 섹션에서는 Stanford Question Answering Dataset(SQuAD) 데이터셋으로 학습된 HuggingFace BERT 모델을 예시로 사용합니다. 자신만의 질의응답 모델을 학습시키거나 미세 조정할 수도 있습니다.

질의응답 시나리오는 질문과 컨텍스트라는 텍스트 조각을 입력으로 받아 컨텍스트에서 추출한 텍스트 문자열인 답변을 생성합니다. 이 시나리오는 질문과 컨텍스트를 토큰화 및 인코딩하고, 입력값을 변환기 모델에 입력하여 컨텍스트에서 가장 가능성이 높은 시작 및 끝 토큰을 생성한 다음, 이를 다시 단어로 매핑하여 답변을 생성합니다.

그런 다음 모델과 스코어링 코드가 온라인 엔드포인트를 사용하여 AzureML에 배포됩니다.

필수 조건

이 튜토리얼의 소스 코드는 GitHub에 게시되어 있습니다.
AzureML에서 실행하려면 다음이 필요합니다.

• Azure 구독

• Azure Machine Learning 작업 영역(작업 영역이 없는 경우 the AzureML configuration notebook을 참조하여 작업 영역을 생성하세요.)

• Azure Machine Learning SDK

• Azure CLI 및 Azure Machine Learning CLI 확장 프로그램(버전 2.2.2 이상)

다음 리소스도 유용할 수 있습니다.

• Azure Machine Learning 아키텍처 및 용어(architecture and terms) 이해

• Azure Portal에서 배포 상태를 추적할 수 있습니다.

AzureML 구독에 액세스할 수 없는 경우 이 자습서를 로컬에서 실행할 수 있습니다.

환경

의존성을 직접 설치하려면 다음 명령을 실행하세요.

pip install torch

pip install transformers

pip install azureml azureml.core

pip install onnxruntime

pip install matplotlib

conda 환경에서 Jupyter 커널을 생성하려면 다음 명령을 실행하세요. <kernel name>을 생성한 커널 이름으로 바꾸세요.

conda install -c anaconda ipykernel

python -m ipykernel install --user --name=<kernel name>

아래 배포 단계에서 사용되는 AzureML CLI 확장 프로그램을 설치하세요.

az login

az extension add --name ml

# azure-cli-ml 확장 프로그램이 설치되어 있으면 제거하세요. az ml 확장 프로그램과 호환되지 않습니다.

az extension remove azure-cli-ml

PyTorch 모델을 가져와 ONNX 형식으로 변환

아래 코드에서는 HuggingFace의 SQUAD 데이터셋을 사용하여 질문 답변에 최적화된 BERT 모델을 가져옵니다.

BERT 모델을 처음부터 사전 학습하려면 Pre-train BERT model의 지침을 따르세요. 자체 데이터셋으로 모델을 미세 조정하려면 AzureML BERT Eval Squa 또는 AzureML BERT Eval GLUE를 참조하세요.

모델 내보내기

PyTorch ONNX 익스포터를 사용하여 ONNX 런타임에서 실행할 수 있는 ONNX 형식의 모델을 생성합니다.

import torch

from transformers import BertForQuestionAnswering

model_name = "bert-large-uncased-whole-word-masking-finetuned-squad"

model_path = "./" + model_name + ".onnx"

model = BertForQuestionAnswering.from_pretrained(model_name)

# 모델을 추론 모드로 설정 (set the model to inference mode)

# 모델을 내보내기 전에 torch_model.eval() 또는 torch_model.train(False)를 호출하는 것이 중요합니다.

# (It is important to call torch_model.eval() or torch_model.train(False) before exporting the model)

# 드롭아웃이나 배치 정규화와 같은 연산자는

# 추론 모드와 학습 모드에서 다르게 동작하기 때문에 모델을 추론 모드로 전환해야 합니다.

# (to turn the model to inference mode. This is required since operators like dropout or batchnorm)

# (behave differently in inference and training mode.)

model.eval()

# 모델에 더미 입력을 생성합니다. 필요에 따라 조정하세요. (Generate dummy inputs to the model. Adjust if necessary)

inputs = {

'input_ids': torch.randint(32, [1, 3], dtype=torch.long), # 토큰화된 텍스트의 숫자 ID 목록

'attention_mask': torch.ones([1, 32], dtype=torch.long), # dummy list of ones

'token_type_ids': torch.ones([1, 32], dtype=torch.long) # dummy list of ones

}

symbolic_names = {0: 'batch_size', 1: 'max_seq_len'}

torch.onnx.export(model, # model being run

(inputs['input_ids'],

inputs['attention_mask'],

inputs['token_type_ids']), # model input (or a tuple for multiple inputs)

model_path, # where to save the model (can be a file or file-like object)

opset_version=11, # the ONNX version to export the model to

do_constant_folding=True, # whether to execute constant folding for optimization

input_names=['input_ids',

'input_mask',

'segment_ids'], # the model's input names

output_names=['start_logits', "end_logits"], # the model's output names

dynamic_axes={'input_ids': symbolic_names,

'input_mask' : symbolic_names,

'segment_ids' : symbolic_names,

'start_logits' : symbolic_names,

'end_logits': symbolic_names}) # variable length axes

ONNX Runtime을 사용하여 ONNX 모델 실행

다음 코드는 ONNX Runtime을 사용하여 ONNX 모델을 실행합니다. Azure Machine Learning에 배포하기 전에 로컬에서 테스트할 수 있습니다.

`init()` 함수는 시작 시 호출되어 토크나이저 및 ONNX 런타임 세션 생성과 같은 일회성 작업을 수행합니다.

`run()` 함수는 Azure ML 엔드포인트를 사용하여 모델을 실행할 때 호출됩니다. 필요한 `preprocess()` 및 `postprocess()` 단계를 추가하세요.

로컬 테스트 및 비교를 위해 PyTorch 모델을 실행할 수도 있습니다.

import os

import logging

import json

import numpy as np

import onnxruntime

import transformers

import torch

# 전처리 함수는 질문과 컨텍스트를 입력받아 모델에 필요한 텐서를 생성합니다.
# - input_ids: 질문에 포함된 단어들을 정수로 인코딩한 것
# - attention_mask: 이 모델에서는 사용되지 않음
# - token_type_ids: 질문의 단어와 컨텍스트의 단어를 구분하는 0과 1로 이루어진 리스트
# 이 함수는 또한 질문과 컨텍스트에 포함된 단어들을 반환하여, 답변을 구문으로 디코딩할 수 있도록 합니다.

# The pre process function take a question and a context, and generates the tensor inputs to the model:

# - input_ids: the words in the question encoded as integers

# - attention_mask: not used in this model

# - token_type_ids: a list of 0s and 1s that distinguish between the words of the question and the words of the context

# This function also returns the words contained in the question and the context, so that the answer can be decoded into a phrase.

def preprocess(question, context):

encoded_input = tokenizer(question, context)

tokens = tokenizer.convert_ids_to_tokens(encoded_input.input_ids)

return (encoded_input.input_ids, encoded_input.attention_mask, encoded_input.token_type_ids, tokens)

# 후처리 함수는 질문과 컨텍스트의 텍스트 토큰을 사용하여 시작 및 종료 로그 확률 목록을 텍스트 답변으로 매핑합니다.

# The post process function maps the list of start and end log probabilities onto a text answer, using the text tokens from the question

# and context.

def postprocess(tokens, start, end):

results = {}

answer_start = np.argmax(start)

answer_end = np.argmax(end)

if answer_end >= answer_start:

answer = tokens[answer_start]

for i in range(answer_start+1, answer_end+1):

if tokens[i][0:2] == "##":

answer += tokens[i][2:]

else:

answer += " " + tokens[i]

results['answer'] = answer.capitalize()

else:

results['error'] = "이 질문에 대한 답을 찾을 수 없습니다. 다른 질문을 해주시겠습니까? I am unable to find the answer to this question. Can you please ask another question?"

return results

# 예측을 위한 일회성 초기화를 수행합니다. 초기화 코드는 엔드포인트가 설정될 때 한 번 실행됩니다.

# Perform the one-off initialization for the prediction. The init code is run once when the endpoint is setup.

def init():

global tokenizer, session, model

model_name = "bert-large-uncased-whole-word-masking-finetuned-squad"

model = transformers.BertForQuestionAnswering.from_pretrained(model_name)

# AZUREML_MODEL_DIR을 사용하여 배포된 모델을 가져옵니다. 여러 모델이 배포된 경우,

# use AZUREML_MODEL_DIR to get your deployed model(s). If multiple models are deployed,

# model_path = os.path.join(os.getenv('AZUREML_MODEL_DIR'), '$MODEL_NAME/$VERSION/$MODEL_FILE_NAME')

model_dir = os.getenv('AZUREML_MODEL_DIR')

if model_dir == None:

model_dir = "./"

model_path = os.path.join(model_dir, model_name + ".onnx")

# Create the tokenizer

tokenizer = transformers.BertTokenizer.from_pretrained(model_name)

# Create an ONNX Runtime session to run the ONNX model

session = onnxruntime.InferenceSession(model_path, providers=["CPUExecutionProvider"])

# Run the PyTorch model, for functional and performance comparison

def run_pytorch(raw_data):

inputs = json.loads(raw_data)

model.eval()

logging.info("Question:", inputs["question"])

logging.info("Context: ", inputs["context"])

input_ids, input_mask, segment_ids, tokens = preprocess(inputs["question"], inputs["context"])

model_outputs = model(torch.tensor([input_ids]), token_type_ids=torch.tensor([segment_ids]))

return postprocess(tokens, model_outputs.start_logits.detach().numpy(), model_outputs.end_logits.detach().numpy())

# Run the ONNX model with ONNX Runtime

def run(raw_data):

logging.info("Request received")

inputs = json.loads(raw_data)

logging.info(inputs)

# Preprocess the question and context into tokenized ids

input_ids, input_mask, segment_ids, tokens = preprocess(inputs["question"], inputs["context"])

logging.info("Running inference")

# Format the inputs for ONNX Runtime

model_inputs = {

'input_ids': [input_ids],

'input_mask': [input_mask],

'segment_ids': [segment_ids]

}

outputs = session.run(['start_logits', 'end_logits'], model_inputs)

logging.info("Post-processing")

# Post process the output of the model into an answer (or an error if the question could not be answered)

results = postprocess(tokens, outputs[0], outputs[1])

logging.info(results)

return results

if __name__ == '__main__':

init()

input = "{\"question\": \"What is Dolly Parton's middle name?\", \"context\": \"Dolly Rebecca Parton is an American singer-songwriter\"}"

run_pytorch(input)

print(run(input))

AzureML을 통해 ONNX 런타임을 사용하여 모델 배포하기

이제 ONNX 모델과 ONNX 런타임을 사용하여 모델을 실행하는 코드가 준비되었으므로 Azure ML을 사용하여 모델을 배포할 수 있습니다.

환경을 확인하세요 (Check your environment)

import azureml.core

import onnxruntime

import torch

import transformers

print("Transformers version: ", transformers.__version__)

torch_version = torch.__version__

print("Torch (ONNX exporter) version: ", torch_version)

print("Azure SDK version:", azureml.core.VERSION)

print("ONNX Runtime version: ", onnxruntime.__version__)

Azure ML 작업 영역 로드

먼저 구성 노트북에서 이전에 생성한 기존 작업 영역에서 작업 영역 개체를 인스턴스화합니다.

참고로, 다음 코드는 노트북과 동일한 디렉터리 또는 .azureml이라는 하위 디렉터리에 구독 정보가 포함된 config.json 파일이 있다고 가정합니다. Workspace.get() 메서드를 사용하여 작업 영역 이름, 구독 이름 및 리소스 그룹을 명시적으로 제공할 수도 있습니다.

import os

from azureml.core import Workspace

ws = Workspace.from_config()

print(ws.name, ws.location, ws.resource_group, ws.subscription_id, sep = '\n')

Now we upload the model and register it in the workspace.

from azureml.core.model import Model

model = Model.register(model_path = model_path, # Name of the registered model in your workspace.

model_name = model_name, # Local ONNX model to upload and register as a model

model_framework=Model.Framework.ONNX , # Framework used to create the model.

model_framework_version=torch_version, # Version of ONNX used to create the model.

tags = {"onnx": "demo"},

description = "HuggingFace BERT model fine-tuned with SQuAd and exported from PyTorch",

workspace = ws)

등록된 모델 목록 보기

이 워크스페이스에 등록된 모든 모델 목록을 볼 수 있습니다.

models = ws.models

for name, m in models.items():

print("Name:", name,"\tVersion:", m.version, "\tDescription:", m.description, m.tags)

# # If you'd like to delete the models from workspace

# model_to_delete = Model(ws, name)

# model_to_delete.delete()

Deploy the model and scoring code as an AzureML endpoint

Note: the endpoint interface of the Python SDK has not been publicly released yet, so for this section, we will use the Azure ML CLI.

There are three YML files in the yml folder:

env.yml: A conda environment specification, from which the execution environment of the endpoint will be generated
endpoint.yml: The endpoint specification, which simply contains the name of the endpoint and the authorization method
deployment.yml: The deployment specification, which contains specifications of the scoring code, model, and environment. You can create multiple deployments per endpoint, and route different amounts of traffic to the deployments. For this example, we will create only one deployment.

The deployment can take up to 15 minutes. Note also that all of the files in the directory with the notebook will be uploaded into the docker container that forms the basis of your endpoint, including any local copies of the ONNX model (which has already been deployed to AzureML in the previous step). To reduce the deployment time remove any local copies of large files, before creating the endpoint.

모델 및 스코어링 코드를 AzureML 엔드포인트로 배포합니다.

참고: Python SDK의 엔드포인트 인터페이스는 아직 공개되지 않았으므로 이 섹션에서는 Azure ML CLI를 사용합니다.

yml 폴더에는 다음 세 개의 YML 파일이 있습니다.

• env.yml: conda 환경 사양으로, 엔드포인트의 실행 환경을 생성하는 데 사용됩니다.

• endpoint.yml: 엔드포인트 사양으로, 엔드포인트 이름과 인증 방법을 포함합니다.

• deployment.yml: 배포 사양으로, 스코어링 코드, 모델 및 환경에 대한 사양을 포함합니다. 엔드포인트당 여러 개의 배포를 생성하고 각 배포로 전송되는 트래픽 양을 다르게 지정할 수 있습니다. 이 예에서는 하나의 배포만 생성합니다.

배포에는 최대 15분이 소요될 수 있습니다. 또한 노트북이 있는 디렉터리의 모든 파일(이전 단계에서 AzureML에 이미 배포된 ONNX 모델의 로컬 복사본 포함)이 엔드포인트의 기반이 되는 Docker 컨테이너에 업로드됩니다. 배포 시간을 단축하려면 엔드포인트를 생성하기 전에 대용량 파일의 로컬 복사본을 모두 제거하십시오.

노트북 파일은 ONNX 모델의 로컬 복사본(이전 단계에서 AzureML에 이미 배포됨)을 포함하여 엔드포인트의 기반이 되는 Docker 컨테이너에 업로드됩니다. 배포 시간을 단축하려면 엔드포인트를 생성하기 전에 대용량 파일의 로컬 복사본을 모두 제거하십시오.

az ml online-endpoint create --name question-answer-ort --file yml/endpoint.yml --subscription {ws.subscription_id} --resource-group {ws.resource_group} --workspace-name {ws.name}

az ml online-deployment create --endpoint-name question-answer-ort --name blue --file yml/deployment.yml --all-traffic --subscription {ws.subscription_id} --resource-group {ws.resource_group} --workspace-name {ws.name}

배포된 엔드포인트 테스트

다음 명령은 배포된 질문-답변 모델을 실행합니다. test-data.json 파일에 테스트 질문이 있습니다. 이 파일을 직접 질문과 컨텍스트로 편집할 수 있습니다.

az ml online-endpoint invoke --name question-answer-ort --request-file test-data.json --subscription {ws.subscription_id} --resource-group {ws.resource_group} --workspace-name {ws.name}

여기까지 진행했다면 ONNX 모델을 사용하여 질문에 답변하는 엔드포인트를 배포한 것입니다.

질문과 컨텍스트를 직접 제공하여 질문에 답변할 수 있습니다!

Azure 리소스 정리

다음 명령은 배포한 AzureML 엔드포인트를 삭제합니다. AzureML 작업 영역, 컴퓨팅 리소스 및 등록된 모델도 정리할 수 있습니다.

az ml online-endpoint delete --name question-answer-ort --yes --subscription {ws.subscription_id} --resource-group {ws.resource_group} --workspace-name {ws.name}

ONNX Runtime 설치

Jay.P Morgan — Thu, 30 Apr 2026 23:17:57 +0900

ONNX Runtime 설치

원하는 운영 체제, 하드웨어, 가속기 및 언어 조합에 대한 권장 설치 지침은 설치 매트릭스를 참조하십시오.

운영 체제 버전, 컴파일러, 언어 버전, 종속 라이브러리 등에 대한 자세한 내용은 호환성 항목을 참조하십시오.

1. ONNX 설치

1.1 요구사항

모든 빌드에는 en_US.UTF-8 로케일이 포함된 영어 언어 패키지가 필요합니다. Linux에서는 locale-gen en_US.UTF-8 및 update-locale LANG=en_US.UTF-8 명령을 실행하여 language-pack-en package 를 설치하십시오.
Windows 빌드에는 Visual C++ 2019 runtime이 필요합니다. 최신 버전을 사용하는 것이 좋습니다.

1.2 CUDA와 CuDnn

ONNX Runtime GPU 패키지를 사용하려면 CUDA와 cuDNN을 설치해야 합니다. 호환되는 CUDA 및 cuDNN 버전을 확인하려면 CUDA execution provider requirements을 참조하십시오.

   •  zlib는 Linux용 cuDNN 9.x에서만 필요합니다(zlib는 cuDNN 9.x Windows 동적 라이브러리에 정적으로 링크됨). 또는 Linux 및 Windows용 cuDNN 8.x에서도 필요합니다. Linux 또는 Windows에 zlib를 설치하려면 cuDNN 8.9 installation guide를 참조하십시오.
   •  Windows에서는 CUDA bin 및 cuDNN bin 디렉터리의 경로를 PATH 환경 변수에 추가해야 합니다.
   •  Linux에서는 CUDA lib64 및 cuDNN lib 디렉터리의 경로를 LD_LIBRARY_PATH 환경 변수에 추가해야 합니다.

onnxruntime-gpu 패키지를 사용하면 CUDA 또는 cuDNN을 수동으로 설치하지 않고도 PyTorch와 함께 사용할 수 있습니다. 자세한 내용은 Compatibility with PyTorch을 참조하십시오.

2. Python 설치

2.1 ONNX Runtime CPU 설치

pip install onnxruntime

INSTALL NIGHTLY

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install --pre --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT-Nightly/pypi/simple onnxruntime

2.2 ONNX 런타임 GPU(DirectML) 설치 - 지속형 엔지니어링 모드

Note: DirectML은 지속적인 엔지니어링 작업이 진행 중입니다. 새로운 Windows 프로젝트에서는 WinML을 사용하는 것을 고려해 보세요.

pip install onnxruntime-directml

INSTALL NIGHTLY

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install --pre --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT-Nightly/pypi/simple onnxruntime-directml

2.3 ONNX 런타임 GPU(CUDA 또는 TensorRT)를 설치하세요.

CUDA 12.X

onnxruntime-gpu in pypi의 기본 CUDA 버전은 1.19.0 버전부터 12.x입니다.

pip install onnxruntime-gpu

For previous versions, you can download here: 1.18.1, 1.18.0

NIGHTLY FOR CUDA 13.X

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install --pre --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ort-cuda-13/nightly/pypi/simple/ onnxruntime-gpu

NIGHTLY FOR CUDA 12.X

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install --pre --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT-Nightly/pypi/simple/ onnxruntime-gpu

CUDA 11.X

CUDA 11.x의 경우, ORT Azure Devops Feed에서 1.19.2 이상 버전을 설치하려면 다음 지침을 따르십시오.

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install onnxruntime-gpu --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-cuda-11/pypi/simple/

For previous versions, you can download here: 1.18.1, 1.18.0

2.4 ONNX 런타임 QNN 설치

pip install onnxruntime-qnn

INSTALL NIGHTLY

pip install coloredlogs flatbuffers numpy packaging protobuf sympy

pip install --pre --index-url https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT-Nightly/pypi/simple/ onnxruntime-qnn

3. C#/C/C++/WinML Installs

3.1 Install ONNX Runtime

INSTALL ONNX RUNTIME CPU

# CPU

dotnet add package Microsoft.ML.OnnxRuntime

INSTALL ONNX RUNTIME GPU (CUDA 12.X)

ORT의 기본 CUDA 버전은 12.x입니다.

# GPU

dotnet add package Microsoft.ML.OnnxRuntime.Gpu

INSTALL ONNX RUNTIME GPU (CUDA 11.8)

(1) Project Setup

Azure Artifacts 키링의 최신 버전을 Github Repo에서 설치했는지 확인하세요.
프로젝트의 .csproj 파일과 동일한 디렉터리에 nuget.config 파일을 추가하세요.

<?xml version="1.0" encoding="utf-8"?>

<add key="onnxruntime-cuda-11"

value="https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-cuda-11/nuget/v3/index.json"/>

</packageSources>

</configuration>

(2) Restore packages

패키지 복원(대화형 플래그를 사용하면 dotnet이 자격 증명을 입력하라는 메시지를 표시합니다.)

dotnet add package Microsoft.ML.OnnxRuntime.Gpu

참고: 매번 -interactive 옵션을 추가할 필요는 없습니다. dotnet은 자격 증명 업데이트가 필요한 경우 -interactive 옵션을 추가하라는 메시지를 표시합니다.

DIRECTML (SUSTAINED ENGINEERING - USE WINML FOR NEW PROJECTS)

dotnet add package Microsoft.ML.OnnxRuntime.DirectML

참고: DirectML은 지속적인 개발 단계에 있습니다. 새로운 Windows 프로젝트에서는 WinML을 대신 사용하십시오.

WINML (RECOMMENDED FOR WINDOWS)

dotnet add package Microsoft.AI.MachineLearning

4. web과 mobile에 설치

pre-built 패키지는 모든 ONNX 연산 집합 및 연산자를 완벽하게 지원합니다.
pre-built 패키지의 크기가 너무 큰 경우 custom build(사용자 지정 빌드)를 생성할 수 있습니다. 사용자 지정 빌드는 모델에 필요한 연산 집합과 연산자만 포함하여 크기를 줄일 수 있습니다.

4.1 JavaScript 설치

INSTALL ONNX RUNTIME WEB (BROWSERS)

# install latest release version

npm install onnxruntime-web

# install nightly build dev version

npm install onnxruntime-web@dev

INSTALL ONNX RUNTIME NODE.JS BINDING (NODE.JS)

# install latest release version

npm install onnxruntime-node

INSTALL ONNX RUNTIME FOR REACT NATIVE

# install latest release version

npm install onnxruntime-react-native

4.2 iOS에 설치

CocoaPods Podfile에 사용하려는 API에 따라 onnxruntime-c 또는 onnxruntime-objc pod를 추가하세요.

C/C++

use_frameworks!

pod 'onnxruntime-c'

OBJECTIVE-C

use_frameworks!

pod 'onnxruntime-objc'

pod install을 실행하세요.

CUSTOM BUILD

custom iOS package 생성 방법에 대한 지침을 참조하십시오.

4.3 Android에 설치

JAVA/KOTLIN

Android Studio 프로젝트에서 다음과 같이 변경하세요.

(1) build.gradle (Project):

repositories {

mavenCentral()

}

(2) build.gradle (Module):

dependencies {

implementation 'com.microsoft.onnxruntime:onnxruntime-android:latest.release'

}

C/C++

MavenCentral에서 호스팅되는 onnxruntime-android AAR 파일을 다운로드하고, 파일 확장자를 .aar에서 .zip으로 변경한 후 압축을 해제하세요. 헤더 폴더의 헤더 파일과 jni 폴더의 관련 libonnxruntime.so 동적 라이브러리를 NDK 프로젝트에 포함시키세요.

CUSTOM BUILD

custom Android package 생성 방법에 대한 지침을 참조하십시오.

5. On-Device Training용 설치

달리 명시되지 않는 한, 이 섹션의 설치 지침은 기기 내 학습을 수행하도록 설계된 사전 구축 패키지를 참조합니다.
사전 구축된 학습 패키지가 모델을 지원하지만 크기가 너무 큰 경우 custom training build를 생성할 수 있습니다.

5.1 Offline 단계 - Training용 준비

Offline Phase - Prepare for Training

python -m pip install cerberus flatbuffers h5py numpy>=1.16.6 onnx packaging protobuf sympy setuptools>=41.4.0

pip install -i https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT/pypi/simple/ onnxruntime-training-cpu

5.2 Training 단계 - On-Device 학습

Device	Language	PackageName	Installation Instructions
Windows	C, C++, C#	Microsoft.ML.OnnxRuntime.Training	dotnet add package Microsoft.ML.OnnxRuntime.Training
Linux	C, C++	onnxruntime-training-linux*.tgz	Download the *.tgz file from here. Extract it. Move and include the header files in the include directory. Move the libonnxruntime.so dynamic library to a desired path and include it.
	Python	onnxruntime-training	pip install onnxruntime-training
Android	C, C++	onnxruntime-training-android	Download the onnxruntime-training-android (full package) AAR hosted at Maven Central. Change the file extension from .aar to .zip, and unzip it. Include the header files from the headers folder. Include the relevant libonnxruntime.sodynamic library from the jni folder in your NDK project.
	Java/Kotlin	onnxruntime-training-android	In your Android Studio Project, make the following changes to: build.gradle (Project): repositories { mavenCentral() } build.gradle (Module): dependencies { implementation 'com.microsoft.onnxruntime:onnxruntime-training-android:latest.release' }
iOS	C, C++	CocoaPods: onnxruntime-training-c	In your CocoaPods Podfile, add the onnxruntime-training-c pod: Run pod install.
	Objective-C	CocoaPods: onnxruntime-training-objc	In your CocoaPods Podfile, add the onnxruntime-training-objc pod: Run pod install.
Web	JavaScript, TypeScript	onnxruntime-web	Use either import * as ort from 'onnxruntime-web/training'; or const ort = require('onnxruntime-web/training');

6. 거대 모델 학습

pip install torch-ort

python -m torch_ort.configure

참고: 이 명령은 특정 CUDA 라이브러리 버전에 매핑된 torch-ort 및 onnxruntime-trainingpackages의 기본 버전을 설치합니다. onnxruntime.ai의 설치 옵션을 참조하십시오.

모든 언어에 대한 추론 설치 표

아래 표는 공식적으로 지원되는 패키지로 제공되는 빌드 변형을 나열합니다. 다른 변형은 각 release branch에서 소스 코드를 직접 빌드할 수 있습니다.

일반적인 requirements 외에도 아래 표에 있는 추가 요구 사항 및 종속성을 참고하십시오.

	Official build	Nightly build	Reqs
Python	If using pip, run pip install --upgrade pip prior to downloading.
	CPU: onnxruntime	onnxruntime (nightly)
	GPU (CUDA/TensorRT) for CUDA 12.x: onnxruntime-gpu	onnxruntime-gpu (nightly)	View
	GPU (DirectML) sustained engineering: onnxruntime-directml	onnxruntime-directml (nightly)	View
	OpenVINO: intel/onnxruntime - Intel managed		View
	TensorRT (Jetson): Jetson Zoo - NVIDIA managed
	Azure (Cloud): onnxruntime-azure
C#/C/C++	CPU: Microsoft.ML.OnnxRuntime	onnxruntime (nightly)
	GPU (CUDA/TensorRT): Microsoft.ML.OnnxRuntime.Gpu	onnxruntime (nightly)	View
	GPU (DirectML) sustained engineering: Microsoft.ML.OnnxRuntime.DirectML	onnxruntime (nightly)	View
WinML recommended for Windows	Microsoft.AI.MachineLearning	onnxruntime (nightly)	View
Java	CPU: com.microsoft.onnxruntime:onnxruntime		View
	GPU (CUDA/TensorRT): com.microsoft.onnxruntime:onnxruntime_gpu		View
Android	com.microsoft.onnxruntime:onnxruntime-android		View
iOS (C/C++)	CocoaPods: onnxruntime-c		View
Objective-C	CocoaPods: onnxruntime-objc		View
React Native	onnxruntime-react-native (latest)	onnxruntime-react-native (dev)	View
Node.js	onnxruntime-node (latest)	onnxruntime-node (dev)	View
Web	onnxruntime-web (latest)	onnxruntime-web (dev)	View

참고: 메인 브랜치에서 생성된 Nightly 빌드는 공식 릴리스 간의 최신 변경 사항을 테스트하는 데 사용할 수 있습니다. 하지만 이러한 빌드를 사용할 경우 발생하는 모든 위험은 사용자 본인이 감수해야 합니다. 야간 빌드는 지원이 제한적이므로 프로덕션 환경에 배포하는 것은 권장하지 않습니다.

모든 언어에 대한 Training 설치 표

더 자세한 설치 지침은 Optimized Training 시작하기 페이지를 참조하세요.

eIQ AI 개발 환경 개요

Jay.P Morgan — Wed, 29 Apr 2026 10:54:59 +0900

◈ eIQ AI 개발 환경 개요

1. eIQ® Time Series Studio for Edge AI Development

웹 액세스 및 온프레미스 설치를 통해 모두 사용 가능합니다.

eIQ® Time Series Studio(TSS)는 NXP 프로세서용 시계열 AI 모델의 생성, 최적화 및 선택을 간소화하는 자동화된 머신 러닝(autoML) 기능을 갖춘 엔드투엔드 개발 도구입니다. TSS는 데이터 큐레이션, 모델 생성, 최적화, 에뮬레이션 및 배포를 포함한 워크플로우를 간소화합니다. 이러한 효율성은 개발 시간과 복잡성을 줄여 임베디드 시스템에 시계열 AI를 빠르고 원활하게 통합하여 실시간 예측 인사이트를 얻을 수 있도록 합니다.

블록도

주요 기능

엔드 투 엔드 개발 파이프라인
• 데이터 큐레이션, 모델 생성, 최적화, 에뮬레이션 및 배포를 간소화합니다.
• 이상 탐지, 분류 및 회귀 작업을 지원합니다.

자동화된 머신 러닝(autoML)
   •  데이터 전처리, 특징 엔지니어링, 모델 선택 및 하이퍼파라미터 튜닝을 자동화합니다.
   •  정확도, RAM 및 플래시 메모리 제약 조건에 최적화된 모델을 한 번의 클릭으로 생성할 수 있습니다.
   •  모델 생성 및 최적화 시간을 몇 주에서 몇 시간으로 단축합니다.

포괄적인 데이터 처리
   •  다양한 소스의 시계열 데이터를 로깅, 가져오기, 정리, 레이블 지정, 정렬 및 탐색합니다.
   •  전압, 전류, 온도, 진동, 압력, 소리, 비행 시간 등 다양한 센서 입력을 지원합니다.
   •  맞춤형 모델 학습을 위해 사용자 지정 채널 및 클래스를 정의할 수 있습니다.
   •  데이터 인텔리전스 유틸리티를 통해 샘플링 속도의 균형을 맞추고 노이즈와 추세를 한눈에 파악할 수 있습니다.

고급 시각화 및 분석
• 데이터 시각화 도구: 원시 데이터, 시계열 데이터, 통계 데이터 및 스펙트럼 데이터
• 대화형 데이터 탐색 및 분석

유연한 모델 개발
   •  명령줄 인터페이스 및 그래픽 인터페이스를 제공합니다. 다양한 요구 사항을 가진 개발자를 위해 설계된 인터페이스
   •  NXP 마이크로컨트롤러 및 애플리케이션 프로세서의 CPU, 신경 처리 장치(NPU) 또는 디지털 신호 처리기(DSP)에 배포 가능
   •  간편한 배포를 위해 사용자 지정 C/C++ 라이브러리와 간단한 API 호출 생성
   •  빠른 프로토타이핑 및 검증을 위한 에뮬레이션 환경 제공
   •  MCUXpresso, CodeWarrior, IAR 및 GNU 컴파일러 컬렉션(GCC)과 호환

엣지 AI 지원
• 저지연, 에너지 효율적인 엣지 AI 애플리케이션에 최적화
• 데이터 개인 정보 보호 강화를 위한 오프라인 도구 제공

BYOD(Bring-Your-Own-Data) 및 BYOM(Bring-Your-Own-Model) 지원

• 수집된 데이터를 사용하여 모델을 처음부터 구축
• 기존 딥러닝 모델을 NXP 플랫폼으로 가져오고 변환하여 배포

2. eIQ® Model Watermarking Technology

데이터 수집 및 머신러닝 모델 학습은 상당한 투자가 필요하며, 데이터 소유권은 중요한 차별화 요소입니다. 그러나 copist는 일반적으로 큰 어려움 없이 모델을 복제하거나 모방할 수 있습니다. 메모리 덤프를 통해 장치에서 모델을 추출하는 것 외에도, 머신러닝 알고리즘의 입력-출력 동작에 접근하는 것만으로도 모델을 복제할 수 있다는 공격 사례가 보고되었습니다. 더욱이, 저작권 및 특허법은 대부분의 머신러닝 모델 관련 지적 재산에 직접적으로 적용되지 않습니다.

주요 기능

• 모델 소유권을 입증하는 데 필요한 보고서, 아티팩트 및 지침을 생성합니다.

• 모델 성능 저하나 정확도 감소 없이 안정적으로 작동합니다.

• 워터마킹을 통한 모델 보호

- 머신러닝 분야에서 데이터 소유권은 기업의 경쟁력입니다.

- 데이터 수집 및 모델 학습에는 상당한 투자가 필요합니다.

- 모델 워터마킹은 모델이 복제되거나 도용되는 경우 지적 재산권을 보호합니다.

• 작동 원리

- 이 도구는 학습 중에 선택된 기본 클래스의 객체에 비밀 이미지를 겹쳐 표시하고, 이 겹쳐진 이미지를 대상 클래스로 표시합니다.

- 실행 중에 비밀 이미지가 겹쳐진 기본 클래스 객체가 제공되면, 모델은 기본 클래스 대신 대상 클래스를 예측하여 원본 모델이 복제되었음을 식별합니다.

3. eIQ® for Arm® CMSIS-NN

Arm CMSIS-NN은 Arm® Cortex®-M 프로세서 코어에서 신경망의 성능을 극대화하고 메모리 사용량을 최소화하는 데 사용되는 효율적인 신경망 커널 모음입니다. NXP eIQ는 간편한 배포를 위해 CMSIS-NN을 다른 모든 Arm CMSIS 구성 요소와 함께 MCUXpresso SDK에 직접 통합했습니다.

CMSIS-NN을 사용하려면 TensorFlow Lite보다 수동 작업이 더 많이 필요하지만, 사용할 수 있는 신경망 연산자 세트가 제한적이라는 단점이 있습니다. 따라서 일부 모델은 지원되지 않습니다. Arm은 또한 네트워크 토폴로지를 분석하고 사용할 적절한 함수를 자동으로 결정하는 변환 스크립트를 제공합니다.

블록도

특징

• MCUXpresso SDK의 미들웨어로 제공됨

• i.MX RT 애플리케이션 프로세서, LPC55S69 MCU 및 Cortex-M 기반 장치를 지원함

• Arm에서 Cortex-M4 및 Cortex-M7 코어에 대한 신경망 지원을 제공하기 위해 개발됨

• CMSIS-NN 개발 흐름이 완전히 오프라인으로 진행되어 M급 플랫폼을 대상으로 하는 바이너리를 생성하므로 TF Lite보다 빠르고 용량이 작음

• 일반적인 모델 레이어(예: 컨볼루션, 완전 연결, 풀링, 활성화 함수)를 구현하기 위한 기본 연산 세트를 지원함

• Caffe 모델을 CMSIS-NN API 호출로 변환하는 Arm의 변환 스크립트를 제공함

4. eIQ® Inference with Arm® NN

eIQ 소프트웨어는 Arm NN SDK를 지원합니다. Arm NN SDK는 신경망(NN) 프레임워크와 NXP의 i.MX 및 Layerscape® 프로세서를 포함한 Arm 머신러닝 프로세서 간의 연결을 제공하는 추론 엔진 프레임워크입니다.

Arm® Cortex®-A 기반 프로세서의 경우, Arm NN은 기존 신경망 프레임워크로 학습된 모델을 Arm Compute Library를 통해 Arm Neon™ 명령어를 활용하는 추론 엔진으로 변환합니다.

NXP는 i.MX 8 GPU 및 i.MX 8M Plus NPU에서 추론을 실행할 수 있도록 Arm NN에 대한 백엔드 지원을 제공합니다. Arm NN은 Caffe, TensorFlow, TensorFlow Lite 및 ONNX 모델과 호환됩니다.

블록도

주요 기능

• Arm Cortex-A CPU 코어, Verisilicon GPU 및 NPU(i.MX 8M Plus)용 추론 엔진

• Caffe, TensorFlow, TensorFlow Lite 및 ONNX 모델 지원

• MobileNet SSD, DeepSpeech v1 및 세그멘테이션 네트워크와 같은 모델 지원

• i.MX 8을 지원하는 Yocto BSP에 Arm NN이 완벽하게 통합됨

자세한 내용은 Arm NN에서 확인하세요.

5. eIQ® Inference with DeepViewRT™

eIQ Inference with DeepViewRT™는 NXP 디바이스 및 신경망 컴퓨팅 엔진 전반에 걸쳐 확장성을 제공하는 플랫폼 최적화 런타임 추론 엔진입니다. 무료로 제공되는 이 추론 엔진은 i.MX RT 크로스오버 MCU(Arm® Cortex®-M 코어), i.MX 애플리케이션 프로세서(Cortex-A 및 Cortex-M 코어, 전용 신경 처리 장치(NPU) 및 GPU)를 포함한 리소스 제약이 있는 디바이스에서 코드 크기를 최소화할 수 있도록 지원합니다.

이 추론 엔진은 Linux® OS 기반 개발을 위한 NXP 표준 Yocto BSP 릴리스와 임베디드 RTOS 지원 MCU 개발을 위한 MCUXpresso SDK 릴리스를 통해 제공됩니다.

블록도

eIQ Inference with DeepViewRT Block Diagram

주요 특징

• i.MX RT 크로스오버 MCU 및 i.MX 8M 제품군 애플리케이션 프로세서에서 머신 러닝 모델 실행에 최적화되어 있습니다.

• Arm® Cortex®-M 및 A 코어, GPU 및 NPU에서 추론을 실행할 수 있습니다.

• NXP MCUXpresso SDK 및 Linux OS 기반 개발을 위한 Yocto BSP 릴리스에 미들웨어로 제공됩니다.

• Au-Zone Technologies와의 독점 파트너십을 통해 구현되었습니다.

6. eIQ® Inference with Glow NN

i.MX RT 크로스오버 MCU용 eIQ 머신러닝(ML) 소프트웨어 개발 환경은 Glow 머신러닝 컴파일러를 지원하여 사전 컴파일(ahead-of-time compilation)을 가능하게 합니다. 컴파일러는 신경망을 오브젝트 파일로 변환하고, 사용자는 이를 바이너리 이미지로 변환하여 기존 런타임 추론 엔진에 비해 성능을 향상시키고 메모리 사용량을 줄입니다.

Glow는 ONNX 모델 형식을 지원하는 PyTorch 머신러닝 프레임워크의 소프트웨어 백엔드로 사용됩니다.

Glow(그래프 로워링) 컴파일러는 신경망을 두 단계의 강력한 타입의 중간 표현으로 변환하기 때문에 이러한 이름이 붙었습니다. 첫 번째 단계에서는 최적화 프로그램이 도메인별 최적화를 수행합니다. 두 번째 단계에서는 컴파일러가 특수 백엔드 하드웨어 기능을 활용하는 최적화를 수행합니다. NXP는 이 두 번째 단계에서 Arm® Cortex®-M 코어와 Cadence® Tensilica® HiFi 4 DSP에 대한 특수 지원을 추가하여 각각 Arm CMSIS-NN 및 HiFi NN 라이브러리를 활용해 성능을 향상시켰습니다.

블록도

eIQ® Inference with Glow NN eIQ® Inference with Glow NN

주요 기능

i.MX RT600, i.MX RT1050, i.MX RT1060 및 기타 크로스오버 MCU 지원

지연 시간을 크게 줄이고 바이너리 크기를 축소하여 엣지에서의 추론 가능

CMSIS-NN 및 Cadence® HiFi NN 라이브러리를 활용하여 신경망 연산자 가속화

MCUXpresso SDK에 포함됨

Glow는 2018년 Facebook에서 Apache License 2.0으로 배포한 오픈 소스 커뮤니티 프로젝트입니다.

7. eIQ® Inference with TensorFlow™Lite

NXP의 Yocto 개발 환경에 통합된 eIQ 소프트웨어는 NXP의 MPU 플랫폼용 TensorFlow Lite를 제공합니다. Google에서 개발한 TF Lite는 TensorFlow(TF) 모델의 간소화된 구현을 제공하며, 사전 융합 활성화 함수 및 양자화 커널과 같은 저지연 기술을 사용하여 더 작고 (잠재적으로) 더 빠른 모델을 구현합니다. 또한 TensorFlow와 마찬가지로 TF Lite는 Eigen 라이브러리를 활용하여 행렬 및 벡터 연산을 가속화합니다.

TF Lite는 FlatBuffers 기반의 모델 파일 형식을 정의합니다. TF의 프로토콜 버퍼와 달리 FlatBuffers는 메모리 사용량이 적어 캐시 라인을 더 효율적으로 활용할 수 있으므로 NXP 장치에서 더 빠른 실행 속도를 제공합니다. TF Lite는 TF 신경망 연산의 일부를 지원하며, 순환 신경망(RNN) 및 장단기 메모리(LSTM) 네트워크 아키텍처도 지원합니다.

블록도

주요 특징

• NXP Yocto BSP 릴리스에 미들웨어로 제공

• i.MX 애플리케이션 프로세서용 NXP eIQ 소프트웨어 지원

• Arm® Cortex®-M, Cortex-A, Verisilicon GPU 및 NPU에서 추론 실행 가능

• TensorFlow보다 빠르고 용량이 작아 Edge 환경에서 추론 시 지연 시간 감소 및 바이너리 크기 축소 가능

• 오픈 소스 라이브러리(Eigen 및 GEMMLOWP)를 사용하여 행렬 및 벡터 연산 가속

• NXP에서 최적화한 GEMMLOWP 구현은 Arm® Cortex®-M7 SIMD 명령어를 사용하여 기본 구현 대비 2~3배 향상된 성능 제공

8. eIQ® Inference with TensorFlow™ Lite Micro

NXP의 i.MX RT 크로스오버 MCU를 포함한 리소스가 제한된 디바이스에서 머신러닝 모델을 실행하도록 최적화된 eIQ의 TensorFlow™ Lite for Microcontroller(TF Micro) 추론 기능을 제공합니다.

기존의 TensorFlow Lite 오픈소스 머신러닝 플랫폼보다 빠르고 작은 TF Micro 구현을 통해 더 낮은 지연 시간과 더 작은 바이너리 크기로 엣지 환경에서 추론이 가능합니다.

블록도

주요 특징

• NXP MCUXpresso SDK의 미들웨어 형태로 제공

• i.MX RT 크로스오버 MCU에서 머신러닝 모델 실행에 최적화

• Arm® Cortex®-M에서 추론 실행 가능

• 낮은 지연 시간과 작은 바이너리 크기로 엣지 컴퓨팅 환경에서 추론 가능

9. eIQ® Toolkit for End-to-End Model Development and Deployment

eIQ Toolkit은 직관적인 GUI(eIQ 포털)와 명령줄 호스트 도구를 통해 NXP EdgeVerse 프로세서에서 머신 러닝 개발을 더욱 빠르고 쉽게 만들어 줍니다.

eIQ Portal은 머신 러닝 솔루션 개발을 간소화하는 직관적인 그래픽 사용자 인터페이스(GUI)입니다. 개발자는 포털 내에서 머신 러닝 모델을 생성, 최적화, 디버깅, 시각화 및 내보낼 수 있습니다. 포털을 통해 데이터셋과 모델을 쉽게 가져오고, AI/ML 애플리케이션을 위한 신경망 모델 및 워크로드를 신속하게 학습 및 배포할 수 있습니다. 또한, 포털의 출력 소프트웨어를 사용하여 런타임 추론 엔진에 원활하게 데이터를 입력할 수 있습니다.

eIQ Toolkit은 코드 예제, 실제 사용 사례 및 다양한 프로세스 흐름 옵션에 대한 가이드라인을 제공합니다. 이러한 옵션에는 인기 프레임워크 기반의 사전 학습된 모델 가져오기, 도구 내에서 모델 개발을 위한 데이터셋 생성, 가져오기 및 증강, 또는 지원되는 추론 엔진을 활용하기 위해 기존 워크플로와 통합하는 방법 등이 포함됩니다.

블록도

주요 기능

eIQ 툴킷

• 그래프 수준 프로파일링 기능과 런타임 인사이트를 제공하여 대상 EdgeVerse™ 프로세서에서 실행되도록 신경망 아키텍처를 최적화할 수 있도록 지원합니다.

• 자동화된 머신 러닝 기능을 갖춘 타임 시리즈 스튜디오(TSS)는 시계열 기반 AI 모델의 개발 및 배포를 간소화하고 가속화합니다.

• ML 애플리케이션 예제가 포함되어 있습니다.

• 사전 학습된 모델 데이터베이스에서 선택하거나 "자체 모델 가져오기"(BYOM)를 사용할 수 있습니다.

• 전이 학습 기능은 "자체 데이터 가져오기"(BYOD) 흐름을 지원하며 사용자가 직접 작성한 데이터를 사용할 수 있도록 지원합니다.

• 내장된 변환 도구를 사용하여 TensorFlow 또는 PyTorch 프레임워크 또는 ONNX 형식의 모델을 가져올 수 있습니다.

eIQ 확장 기능

• NXP 장치에 사전 학습된 비전 ML 모델을 배포하기 위한 NVIDIA TAO 툴킷 통합

• 모델 IP 보호

• 분류 및 객체 감지를 위한 설명 가능한 AI

ONNX Runtime 소개

Jay.P Morgan — Tue, 28 Apr 2026 18:34:45 +0900

1. ONNX Runtime 소개

ONNX Runtime은 하드웨어별 라이브러리를 통합할 수 있는 유연한 인터페이스를 갖춘 크로스 플랫폼 머신러닝 모델 가속기입니다. ONNX Runtime은 PyTorch, TensorFlow/Keras, TFLite, scikit-learn 및 기타 프레임워크의 모델과 함께 사용할 수 있습니다.

1.1 ONNX Runtime 추론

ONNX 런타임 추론은 Office, Azure, Bing을 비롯한 주요 Microsoft 제품 및 서비스와 수십 개의 커뮤니티 프로젝트에서 머신 러닝 모델을 구동합니다.

ONNX 런타임 추론의 사용 사례는 다음과 같습니다.

다양한 머신 러닝 모델의 추론 성능 향상
다양한 하드웨어 및 운영 체제에서 실행
Python으로 학습하고 C#/C++/Java 앱에 배포
다양한 프레임워크로 생성된 모델을 사용하여 학습 및 추론 수행

1.2 작동 방식

기본 원리는 간단합니다.

모델을 준비합니다. 이 모델은 ONNX 형식으로 내보내기/변환을 지원하는 모든 프레임워크에서 학습할 수 있습니다. 인기 있는 프레임워크/라이브러리에 대한 튜토리얼을 참조하세요.

ONNX 런타임을 사용하여 모델을 로드하고 실행합니다. 다양한 언어로 작성된 모델을 실행하는 기본 튜토리얼을 참조하세요.

(선택 사항) 다양한 런타임 구성 또는 하드웨어 가속기를 사용하여 성능을 최적화합니다. 다양한 옵션이 있으므로 성능 섹션을 참조하세요.

3단계를 거치지 않더라도 ONNX Runtime은 기존 프레임워크에 비해 성능 향상을 제공하는 경우가 많습니다.

ONNX Runtime은 모델 그래프에 여러 그래프 최적화를 적용한 후, 사용 가능한 하드웨어별 가속기를 기반으로 그래프를 서브그래프로 분할합니다. ONNX Runtime 코어의 최적화된 연산 커널은 성능 향상을 제공하며, 할당된 서브그래프는 각 실행 공급자(Execution Provider)로부터 추가적인 가속을 받습니다.

1.3 모델 검증

ONNX Runtime과 함께 사용하는 모든 모델은 정확성, 성능 및 사용 목적에의 적합성을 포함하여 테스트 및 검증을 거쳐야 합니다. ONNX Runtime은 모델이 ONNX 사양을 준수하는지 검증합니다. 그러나 불필요하게 많은 양의 메모리나 컴퓨팅 리소스를 소비하는 악의적인 모델을 구축할 수도 있습니다. 신뢰할 수 없는 출처에서 제공된 모델을 사용하는 경우, 프로덕션 환경에서 사용하기 전에 안전한 환경에서 모델을 검사하고 테스트하는 것이 좋습니다.

2. ONNX 설치

2.1 Android에 설치

JAVA/KOTLIN
Android Studio 프로젝트에서 다음 부분을 수정하세요.

1. build.gradle (Project):

repositories {

mavenCentral()

}

2. build.gradle (Module):

dependencies {

implementation 'com.microsoft.onnxruntime:onnxruntime-android:latest.release'

}

C/C++

MavenCentral에서 onnxruntime-android AAR 파일을 다운로드하고, 파일 확장자를 .aar에서 .zip으로 변경한 후 압축을 해제하세요. 헤더 폴더의 헤더 파일과 jni 폴더의 관련 libonnxruntime.so 동적 라이브러리를 NDK 프로젝트에 포함시키세요.

사용자 지정 빌드

custom Android 패키지 생성 지침을 참조하세요.

2.2 On-Device Training용 설치

별도로 명시되지 않는 한, 이 섹션의 설치 지침은 온디바이스 학습을 수행하도록 설계된 사전 구축된 패키지를 기준으로 합니다.
사전 구축된 학습 패키지가 모델을 지원하지만 크기가 너무 큰 경우, custom training build를 생성할 수 있습니다.

오프라인 단계 : 학습 준비

python -m pip install cerberus flatbuffers h5py numpy>=1.16.6 onnx packaging protobuf sympy setuptools>=41.4.0

pip install -i mhttps://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/ORT/pypi/simple/ onnxruntime-training-cpu

학습단계 - On-Device Training

Device	Language	PackageName	Installation Instructions
Windows	C, C++, C#	Microsoft.ML.OnnxRuntime.Training	dotnet add package Microsoft.ML.OnnxRuntime.Training
Linux	C, C++	onnxruntime-training-linux*.tgz	Download the *.tgz file from here. Extract it. Move and include the header files in the include directory. Move the libonnxruntime.so dynamic library to a desired path and include it.
	Python	onnxruntime-training	pip install onnxruntime-training
Android	C, C++	onnxruntime-training-android	Download the onnxruntime-training-android (full package) AAR hosted at Maven Central. Change the file extension from .aar to .zip, and unzip it. Include the header files from the headers folder. Include the relevant libonnxruntime.sodynamic library from the jni folder in your NDK project.
	Java/Kotlin	onnxruntime-training-android	In your Android Studio Project, make the following changes to: build.gradle (Project): repositories { mavenCentral() } build.gradle (Module): dependencies { implementation 'com.microsoft.onnxruntime:onnxruntime-training-android:latest.release' }
iOS	C, C++	CocoaPods: onnxruntime-training-c	In your CocoaPods Podfile, add the onnxruntime-training-c pod: Run pod install.
	Objective-C	CocoaPods: onnxruntime-training-objc	In your CocoaPods Podfile, add the onnxruntime-training-objc pod: Run pod install.
Web	JavaScript, TypeScript	onnxruntime-web	Use either import * as ort from 'onnxruntime-web/training'; or const ort = require('onnxruntime-web/training');

Brief Linux Kernel v7.0

Jay.P Morgan — Sun, 26 Apr 2026 07:25:53 +0900

1. Brief Linux Kernel v7.0

기존의 6.x 대 커널을 넘어 Linux Kernel v7.0 시대(2026년 기준)에 접어들면서, 리눅스는 단순히 운영체제의 커널을 넘어 초병렬화(Massive Parallelism)와 하드웨어 가속기와의 완전한 융합을 목표로 진화했습니다.

v4.19에서 v6.12를 거쳐 v7.0까지 오며 바뀐 핵심적인 변화들을 짚어드릴게요.

1. 스케줄러의 대변혁: EEVDF의 정착과 확장

과거의 CFS(Completely Fair Scheduler)는 v6.6 무근에서 EEVDF(Earliest Eligible Virtual Deadline First) 스케줄러로 완전히 교체되었습니다.

v7.0의 특징: EEVDF가 더욱 정교해져서, 이제는 CPU뿐만 아니라 NPU(신경망 처리 장치)와 GPU의 타임 슬라이스까지 커널 스케줄러가 직접 관리합니다.
구조적 변화: struct rq 내에 단순히 curr를 두는 것을 넘어, 이종 컴퓨팅 자원 간의 태스크 마이그레이션을 위한 sched_group 인터페이스가 대폭 강화되었습니다.

2. Rust-in-Linux의 완전한 주류화

4.19 시절에는 상상도 못 했던 변화입니다. v6.x 대에서 실험적으로 도입된 Rust 언어가 v7.0에 이르러서는 커널 핵심 서브시스템의 표준이 되었습니다.

메모리 안전성: 드라이버뿐만 아니라 파일 시스템(NVMe, 비디오 드라이버 등)의 상당 부분이 Rust로 재작성되어, C언어 고유의 'Dangling Pointer'나 'Use-after-free'로 인한 커널 패닉이 극적으로 줄어들었습니다.
빌드 시스템: Kbuild 시스템이 Rust와 C를 병렬로 완벽하게 처리하며, LLVM/Clang이 GCC와 대등한 수준의 기본 컴파일러로 자리 잡았습니다.

3. 메모리 관리: MGLRU와 계층적 메모리

메모리 관리(MM) 측면에서는 MGLRU(Multi-Gen LRU)가 완전히 최적화되었습니다.

v7.0의 메모리: 단순 RAM뿐만 아니라 CXL(Compute Express Link) 기반의 확장 메모리를 커널이 '계층형'으로 인식합니다.
자주 쓰지 않는 데이터는 커널이 스스로 판단하여 저속 CXL 메모리로 보내고, 응답 속도가 중요한 데이터는 프로세서 근처의 HBM(High Bandwidth Memory)에 배치하는 알고리즘이 struct page 구조체 수준에서 통합되었습니다.

4. 보안: 경계 없는 샌드박싱 (Landlock & eBPF)

커널 보안 모델이 "전체를 막는 방식"에서 "태스크 단위의 미세 샌드박싱"으로 바뀌었습니다.

eBPF의 진화: 이제 eBPF는 단순한 모니터링 도구가 아니라, 커널 코드 수정 없이도 커널의 동작을 실시간으로 커스텀하는 '커널 내 가상 머신' 역할을 수행합니다.
Landlock: 유저 레벨 어플리케이션이 스스로 접근 권한을 제한하는 Landlock LSM이 기본 활성화되어, 브라우저나 서버 프로세스가 뚫리더라도 시스템 전체로 전이되는 것을 원천 차단합니다.

5. 실시간성(PREEMPT_RT)의 메인라인 통합 완료

오랜 숙원 사업이었던 실시간 패치(RT Patch)가 v7.0에 이르러서는 별도의 패치 없이도 커널 메인라인에 완전히 녹아들었습니다. 덕분에 일반 범용 리눅스 커널로도 산업용 로봇이나 정밀 제어 시스템을 운영할 수 있게 되었습니다.

요약하자면

구분	v4.19 (과거)	v7.0 (현재/미래)
스케줄러	CFS (Fairness 위주)	EEVDF (Deadline & Latency 위주)
주요 언어	Pure C	C + Rust (Memory Safety)
메모리	단순 RAM 관리	CXL 기반 계층형 메모리 관리
보안	전통적인 권한 모델	eBPF 기반의 미세 동적 보안

v4.19에서 struct rq를 보시다가 v7.0 소스코드를 보시면, 파일 구조는 비슷해 보여도 그 내부를 흐르는 자원 관리의 철학이 "보안"과 "효율적 분산 처리"로 완전히 옮겨갔음을 느끼실 수 있을 겁니다.

2. 리눅스 7.0 출시 예정: 차기 주요 커널 릴리스에서 기대할 수 있는 사항

2026. 02. 24

https://www.linuxjournal.com/content/linux-70-coming-what-expect-next-major-kernel-release

리눅스 커널 프로젝트가 차기 주요 릴리스인 리눅스 커널 7.0을 향해 나아가면서 오픈소스 세계의 기대감이 고조되고 있습니다. 주요 버전 번호가 바뀐다는 것은 극적인 변화를 의미하는 것처럼 들릴 수 있지만, 실제로는 훨씬 더 꾸준한 발전이며, 바로 이러한 꾸준한 발전이 리눅스 커널을 그토록 안정적이고 신뢰할 수 있는 운영체제로 만들어주는 요소입니다. 리눅스 7.0의 첫 번째 릴리스 후보(RC1)가 이미 공개되었으며, 개발자들은 2026년 4월 중순경으로 예상되는 안정 버전 출시를 위한 마지막 단계에 접어들었습니다.

혁명이 아닌 진화

리눅스 커널의 창시자이자 주요 관리자인 리누스 토르발스는 리눅스 6.19 이후의 차기 버전이 리눅스 7.0으로 명명될 것이라고 공식적으로 발표했습니다. 그는 발표에서 "7.0"으로의 도약이 엄청난 아키텍처적 변화를 의미하는 것이 아니라, 버전 번호를 관리하기 쉽게 하기 위한 실용적인 명명 결정이라고 밝혔습니다.

이러한 전통은 오랜 패턴을 이어가고 있습니다. 커널 시리즈는 일반적으로 마이너 버전(예: 6.19)이 높아질 때까지 번호가 매겨지고, 그 이후에는 변경 사항이 기존 기능을 깨뜨리는 것이 아니라 점진적이고 대부분 추가적인 방식이더라도 메이저 버전 번호가 증가합니다.

리눅스 7.0 개발 주기

리눅스 7.0 개발 주기는 전 세계 기여자들의 새로운 코드를 수용하는 병합 기간으로 시작되었습니다. 현재 릴리스 후보 단계가 진행 중이며, 안정화 및 테스트에 초점이 맞춰지고 있습니다.

7.0-rc1 발표에서는 이번 주기에서 병합 기간이 "순조롭게" 진행되었으며, 리드 개발자의 테스트 머신에서 주요 부팅 오류가 비교적 적게 보고되었다고 언급했습니다. 이는 커널의 광범위한 하드웨어 지원을 보여주는 좋은 징조입니다.

예상되는 개선 사항

안정화된 7.0 커널의 최종 변경 사항은 출시될 때 공개되겠지만, 초기 미리 보기 및 보고를 통해 다음과 같은 몇 가지 주요 특징이 두드러집니다.

1. 광범위한 하드웨어 지원

현재까지 변경 사항의 상당 부분은 드라이버 업데이트로, Linux가 Intel, AMD, Qualcomm과 같은 벤더의 최신 CPU 및 SoC를 지원하도록 합니다. 초기 테스트 결과 Intel Nova Lake 및 AMD Zen 6와 같은 새로운 제품군에 대한 지원이 확인되었으며, 이는 차세대 노트북, 데스크톱 및 서버에 중요한 역할을 할 것입니다.

2. 성능 및 응답성

커널 관리자와 커뮤니티 보고에 따르면 성능 향상이 7.0 버전의 주요 특징 중 하나입니다. 구체적인 내용은 아직 밝혀지지 않았지만, 커널의 스케줄러 및 메모리 관리 하위 시스템은 워크로드가 다양해짐에 따라 지속적으로 최적화되는 경향이 있습니다.

3. 파일 시스템 및 하위 시스템 개선

내부적으로 파일 시스템, 네트워킹 및 코어 라이브러리와 같은 기본 구성 요소가 안정성과 효율성 향상을 위해 개선되고 있습니다. 이러한 변화들이 헤드라인을 장식하는 주요 기능으로 보이지는 않지만, 대용량 스토리지 어레이부터 고속 네트워킹에 이르기까지 Linux의 처리 성능에 큰 영향을 미칩니다.

버전 번호의 진정한 의미

Linux 7.0에서 가장 많이 논의되는 부분 중 하나는 기술적인 측면이 아니라 바로 버전 번호 자체입니다. 토르발스는 주요 버전 번호가 과거와 극적인 단절을 의미하는 것이 아니라, 버전 관리의 단순성과 명확성을 위한 것이라고 여러 차례 설명했습니다. 그의 말에 따르면, 이러한 변화는 단순히 하위 버전 번호를 관리하는 번거로움을 피하고 개발 과정을 명확하게 보여주기 위한 것이기도 합니다.

이는 중요한 사실을 시사합니다. Linux의 버전 관리는 마케팅이나 제품 출시 주기에 따라 좌우되지 않습니다. 대규모 기능 추가를 알리기 위해 버전 업데이트를 사용하는 상용 소프트웨어와 달리, Linux의 버전 번호는 실용적이며 개발 프로세스에 특화되어 있습니다.

안정화 버전은 언제 출시될까요?

RC1이 이미 출시된 Linux 7.0의 안정 버전은 기존의 주간 릴리스 후보(RC1) 출시 주기 이후에 출시될 것으로 예상됩니다. 과거 패턴을 기반으로 하고, 중대한 퇴보가 없다고 가정할 때, 최종 릴리스는 약 7번의 RC 빌드 이후인 2026년 4월 중순경으로 예상됩니다.

안정화되면 Linux 7.0은 차세대 Ubuntu LTS, Fedora 및 최신 커널 기능을 우선적으로 제공하는 주요 배포판을 포함한 후속 릴리스 주기에서 채택될 것으로 예상됩니다.

사용자에게 중요한 이유

대부분의 일반 사용자, 특히 데스크톱 및 노트북 사용자에게 커널 변경 사항은 눈에 띄지 않게 작동합니다. 화려한 새 데스크톱 기능을 보지 못할 수도 있지만, 시간이 지남에 따라 다음과 같은 변화를 체감할 수 있습니다.

새로운 프로세서 및 주변 장치에 대한 향상된 지원
고부하 작업 시 성능 향상
저장 장치, 메모리 및 전원 관리의 원활함
새로운 커널 트리에 포함된 보안 및 안정성 수정 사항
즉, Linux 7.0은 혁명적인 변화가 아니라 차세대 하드웨어 및 소프트웨어 요구 사항에 대비한 개선 및 준비입니다.

결론

리눅스 7.0으로의 업그레이드가 단순히 숫자로만 주목받는 것은 아니지만, 그 이면에는 리눅스 커널의 꾸준한 진화의 연장선상에 있는 미묘한 의미가 담겨 있습니다. 광범위한 하드웨어 지원, 지속적인 성능 개선 작업, 그리고 안정성을 최우선으로 고려한 개발 프로세스를 통해 2026년 출시될 리눅스 7.0은 커널을 최신 상태로 유지하고, 강력한 성능을 제공하며, 일상적인 사용에 항상 대비할 수 있도록 할 것입니다.

Electronic Artist

NUMA

NUMA (Non-Uniform Memory Access)

1. 초보자 가이드

2. NUMA 탄생 배경과 기초 개념

3. NUMA 하드웨어 토폴로지

4. ACPI를 통한 NUMA 토폴로지 검색

5. 커널 자료구조: pglist_data

6. NUMA 메모리 정책

7. Automatic NUMA Balancing

8. NUMA-aware 스케줄링

9. 페이지 마이그레이션

10. NUMA-aware 서브시스템

11. NUMA와 메모리 회수 (Memory Reclaim)

12. MNUMA-aware I/O

12. CXL과 이종 NUMA

13. 가상화 (Virtualization)와 vNUMA

14. 성능 분석과 최적화

15. 커널 설정 종합

15. 트러블 슈팅

16. 흔한 실수와 안티패턴

17. NUMA 초기화 흐름

18. NUMA와 cgroups 통합

19. NUMA 메모리 핫플러그

20. NUMA와 Hugepage

21. NUMA 배치 최적화 플레이북

22. task_numa_fault() → task_numa_placement() 체인

23. struct numa_group 심층 분석

24. NUMA 페이지 마이그레이션 경로 분석

25. NUMA 메모리 정책 커널 경로

26. NUMA 스코어 계산과 노드 배치 최적화

27. Linux 6.12 ~ 6.19 NUMA 최신 동향

28. 참고자료

# 관련 문서

AP-A2B-DSP

1. AP-DSP 사에의 A2B Transceiver 2EA

빅데이터 분석기사와 AI

1. 빅데이터 분석기사 개요

2. 빅데이터 분석기사와 인공지능(AI) 대학원

I2S (Inter-IC Sound)

◈ I2S (Inter-IC Sound)

I2S 기술의 세부사항

기술의 동작

기술의 구현

ADI - DAI와 NXP - SAI

◈ ADI - DAI와 NXP - SAI

2. ADI DSP와 NXP HeadUnit의 Pin 매칭

ONNX Tutorial

1. ONNX Runtime Inferencing: API Basics

2. Accelation PyTorch

Export model to ONNX

Accelerated inference with ONNXRuntime

RESNET-50

ONNX Runtime을 사용하여 다양한 하드웨어 환경에서 PyTorch 모델 추론하기

설정

ResNet-50 데모

추론을 위한 전처리 설정(Set up Pre-Processing for Inference )

ONNX 런타임을 사용하여 ResNet-50 ONNX 모델 추론하기

PyTorch와의 비교

OpenVINO와의 비교

Conclusion

결론

비디오 데모

ORTModule Examples

2. Accelating TensorFlow

Accelerate TensorFlow model inferencing

Get Started

Export model to ONNX

TensorFlow/Keras

TFLite

3. Accelerate Hugging Face models

Accelerate Hugging Face model inferencing

Additional resources

4. AzureML에서 ONNX 런타임을 사용하여 고성능 질의응답 모델 배포하기

목차

필수 조건

환경

PyTorch 모델을 가져와 ONNX 형식으로 변환

ONNX Runtime을 사용하여 ONNX 모델 실행

AzureML을 통해 ONNX 런타임을 사용하여 모델 배포하기