← Docs hub

ONDEVICE 메모리 분석 — 결론과 대응 판단

현재 결론: TTS의 합성 후 메모리 보유는 줄일 수 있다. NPU 초기화의 IOVA 할당 실패와 범위 밖 할당을 허용하는 경계 결함도 확인했다. 그러나 현장 Swap 약 3GB와 LMKD의 직접 원인은 아직 확정하지 못했다.

세 현상을 하나의 원인으로 묶으면 안 된다. 아래는 10/16~18 실측과 10/19 추가 조사에 따른 판단이며, 상세 원문은 시험 근거 모음에 보존했다.

1. 무엇을 알아냈고, 무엇을 결정할 수 있나

우선 적용 판단: TTS 회수는 성능·메모리 절충 옵션으로 검토할 수 있다. IOVA는 커널/FastRPC 주소 할당을 별도 조사해야 한다. 현장 3GB에 대해서는 소유 영역을 확인하기 전 모델 교체·Swap 축소·LMKD 완화부터 적용할 근거가 없다.

2. NPU인데 왜 RAM과 RSS를 같이 보나

현재 시험에서 LLM FastRPC 매핑은 약 1,708MiB, 그중 최대 단일 요청은 1,688MiB였다. 시스템 전체 DMA-BUF 약 1.9GiB에는 카메라 등도 포함된다. 세 수치는 같은 숫자의 오차가 아니라 집계 대상이 다르다. NPU 사용이 호스트 메모리 사용을 없애지는 않으며, STT/TTS의 CPU 메모리도 시스템 RAM을 함께 사용한다.

3. TTS ON/OFF: 무엇을 회수하고 무엇을 얻나

OFF는 합성 중 확보한 ORT CPU arena 영역을 다음 합성에서 재사용하도록 유지한다. 이는 반복 할당을 줄이려는 성능상 이유가 있다. ON은 Run 후 완전히 비어 있는 arena 영역의 반환을 요청한다. 모델·세션 전체를 unload하거나 사용 중인 PCM을 버리는 변경이 아니다. STT/QNN 메모리 회수 스위치도 아니다. arena 정책과 하위 allocator 캐시에 따라 모두 즉시 RSS에서 빠진다고 보장하지 않는다.

긴 생성의 전체 소요시간 차이다. 첫 음성 출력이 항상 0.23초 늦는다는 측정은 아니다. 표본이 작으며 제품 동시 부하에서의 감소량·지연을 그대로 보장하지 않는다. 제품 TTS 14회 시험의 설치 라이브러리는 전달용 ON/OFF와 해시가 일치하지 않아 해당 시험을 A/B 증거로 사용하지 않는다. 해당 제품 시험에서 Scudo는 마지막 반복 10회 동안 약 1.29MiB 증가했으며, 초기 증가 뒤 재사용되는 양상과 부합했다.

4. IOVA 초기화 실패: RAM이 남는데 왜 실패하나

확정된 흐름: 1,688MiB 매핑 요청 → 관리 구조체 할당 성공 → IOVA 할당 실패 → 캐시 주소 반환 후 재시도 실패 → dma_buf_map_attachment ... ret -12 → Failed to map weights buffer to device → Genie 초기화 실패.

해당 실패 전후 모델 해제 상태의 MemAvailable은 약 5GiB였다. 이는 실패 순간의 정밀 RAM 표본은 아니지만, 추적한 실패 반환점이 IOVA라는 사실과 함께 보아 일반적인 RAM 부족으로만 설명할 수 없다.

설정된 장치 주소 범위는 0x80000000부터 크기 0x78000000, 즉 1,920MiB다. 큰 요청 1,688MiB를 배치하면 산술 잔여는 232MiB지만, 작은 기존 매핑이 중간을 점유하면 필요한 크기의 연속 주소를 확보하지 못할 수 있다. 전체 빈 공간 합계와 최대 연속 구간은 다르다.

초기 조사에서 분리한 두 후보 — 아래 후속 40회 시험으로 일부 확정:

• 기존 작은 매핑의 위치 때문에 합법 범위 안에 1,688MiB 연속 구간이 없음.
• allocator의 캐시 탐색·경계 처리에 문제가 있음. 이전 성공 시험에서 반환 IOVA가 설정 시작 주소보다 낮은 사례가 있어 정상 성공 여부도 재검토해야 함.

초기에는 로컬 소스의 unsigned overflow 가능성만 확인했다. 후속 시험에서는 실행 코드와 레지스터 값까지 확인해 경계 결함을 확정했다. 다만 과거 최종 DMA -12의 모든 원인까지 확정한 것은 아니다. 단순 재시도 성공이나 IOVA 풀 확대만으로 해결됐다고 판정해서도 안 된다.

10/19 추가 실측: 작은 주소 점유가 큰 요청을 막는 사례

같은 네이티브 프로세스에서 모델 생성·해제를 12회 모두 완료했다. 별도 압박 프로세스는 추가하지 않았다. 1,688MiB 요청 12건 중 2건은 첫 alloc_iova가 NULL을 반환했고 내부 재시도에서 성공했다. 12건의 최종 주소는 모두 설정 범위 안이었다. 최종 DMA -12는 이번에 재현되지 않았다.

해석: 작은 주소 점유의 위치가 큰 연속 매핑을 방해하는 구체적 배치를 확인했다. 큰 요청 크기만 줄이거나 RAM 잔량만 보는 접근은 부족하다. 다만 이번에는 해당 노드의 삭제 이벤트와 객체 소유자를 직접 수집하지 않아, “특정 FastRPC 버퍼를 회수해서 해결됐다”까지 확정하지 않는다. 내부 재시도 경로에서 성공했다는 사실과 주소 트리의 변화가 증거다.

이번 표본 MemAvailable은 약 2.54~4.70GiB였지만, 이는 초기화 전후 표본이며 할당 실패 순간 값은 아니다. trace는 16,296/16,296개가 보존됐고 alloc 반환 probe는 전체적으로 4회 누락이 있었으나 대상 큰 요청 14회(재시도 포함)는 진입·반환 쌍을 확보했다. 같은 PID여도 중간에 IOVA 도메인 주소가 바뀌어 전체 회차를 동일 도메인 누적 시험으로 보지 않는다. 네이티브 프로세스 종료와 진단 probe 제거를 확인했다.

시험 중 카메라 등 다른 프로세스의 종료가 관측됐고, 시험 종료 후 제품 앱 초기화에서도 LMKD가 세 차례 발생했다. 따라서 이 시험은 무압박·무간섭 기준선이 아니다. NPU 매핑 성공과 제품 전체 초기화 생존성을 구분한다. 최종 복구 PID 27842에서 LLM·STT·TTS 초기화 성공과 STATE_PRE_RECORDING 진입을 확인했다. 진단 프로세스와 probe는 남아 있지 않다.

IOVA 건의 현 단계 결론: 실패 계층은 장치 주소 할당으로 확정했고, 작은 주소 점유에 따른 연속 구간 부족을 뒷받침하는 재현 근거를 추가했다. 이 12회 시점에는 과거 최종 -12의 잔존 객체 소유자와 경계 결함이 미확정이었다. 이어진 40회 시험에서는 별도 재현의 FastRPC 매핑과 실제 경계 결함을 확인했다. SoC 쪽 수정 검증에서는 전체 주소 트리·해제 이벤트·실행 커널 경계 분기를 같은 실패에서 확보해야 한다. 캐시 반환 뒤에도 실패한 과거 사례가 있으므로 단순 재시도만으로 해결됐다고 결론내리지 않는다.

10/19 후속 40회: 캐시 예약과 경계 결함을 분리 확인

새 결론: 일시적인 IOVA 실패 중에는 이미 반환 가능한 작은 주소 예약이 큰 연속 할당을 막는 경우가 있다. 또 재시도 중 설정 하한이 0으로 바뀌어 범위 밖 주소를 반환하는 allocator 경계 결함을 실제 실행에서 확인했다. 따라서 GenieDialog_create=0만으로 정상적인 장치 주소 배치라고 판정할 수 없다.

40회 모두 API 생성·해제는 완료했다. 하지만 2회의 주소 경계 이탈 때문에 40회 정상 매핑 통과라고 표현하지 않는다. 최종 DMA -12는 이번 추가 40회에서는 발생하지 않았다.

A. 캐시 예약 때문에 실패했다가 회복한 13건

각 실패 호출의 주소 탐색에서 작은 4KiB 노드를 확인했고, 같은 스레드의 CPU 0~7 IOVA 캐시 정리 과정에서 그 노드의 rb_erase 이벤트를 포착했다. 이어 같은 1,688MiB 요청이 정상 범위에서 성공했다. 단순히 “캐시가 원인일 수 있다”에서 해당 주소 노드 삭제와 성공의 연결을 관측한 단계로 좁혔다. 이 캐시는 TTS arena나 Swap이 아닌 커널 IOVA 주소 예약 캐시다.

B. 잔존 FastRPC 매핑과 범위 밖 성공을 확인한 사례

동일 주소의 재사용을 혼동하지 않도록 실패 시점을 포함하는 매핑 생존 구간을 비교했다.

FastRPC 로그의 상위 context-bank 표기를 제외한 하위 IOVA를 비교했다. 로컬 adsprpc.c는 cb << 32를 주소에 합치는 경로를 포함한다. 방해 노드 PFN 0x8a3ff는 작은 버퍼의 IOVA 0x8a3ff000과 일치하고, 그 위의 빈 구간은 1,686MiB로 필요한 1,688MiB보다 작았다. 실패 시점에는 map 이후·unmap 이전이므로, 이 사례의 노드는 단순히 삭제 가능한 CPU IOVA 캐시 예약으로 볼 수 없다. 다만 QNN 내부의 정확한 버퍼 명칭·업무 용도까지 특정하지는 않았다.

C. 실행 코드와 알려진 수정 방식 대조

보드의 실행 중인 alloc_iova 기계어를 읽었고, 경계 처리 구간 +0x230~+0x2c8의 39개 명령이 로컬 빌드와 일치했다. 전체 커널 이미지 동일성을 주장하는 검사는 아니다. 이 구간은 anchor의 최대 unsigned PFN에 먼저 1을 더하고, 재시도 하한에 그 값을 넣는 동작을 포함한다. 위 레지스터 기록은 실제로 값이 0이 된 경로를 증명한다.

Android 공통 커널에는 같은 overflow 유형의 수정 이력이 있다. 덧셈 이전 값으로 범위를 비교한 뒤 재시도에 진입할 때만 1을 더하도록 바꾼다. Android common 수정 원문

관측한 주소 트리 상단을 사용한 호스트 알고리즘 모델에서도 기존 분기는 0x20a00을 반환하고, 수정 방식은 해당 배치에서 할당 실패를 반환했다. 정상 연속 공간이 있는 대조 조건에서는 양쪽 모두 합법 주소를 반환했다. 이것은 분기 동작 검증이며, 보드 커널 패치·제품 회귀 시험은 아니다. 실제 기기의 커널이나 라이브러리를 교체하지 않았다.

현실적인 수정 순서와 남은 범위

1. SoC 커널 담당: overflow 수정의 5.4 vendor 커널 적용성 검토. 수정 후 모든 대형 매핑이 [0x80000000, 0xf8000000) 안에 있는지를 합격 기준으로 삼는다.
2. QNN/FastRPC 담당: 대형 weights 매핑 전에 생성된 작은 버퍼의 배치·수명 확인. 유효한 매핑을 임의로 해제하지 않고, 매핑 순서 조정·별도 도메인·배치 정책 등의 지원 가능성을 검토한다.
3. 수정 검증: 경계 결함 수정은 비정상 성공을 올바른 실패로 바꿀 수 있다. 주소 배치 개선과 함께 반복 초기화 성공률·해제·정상 추론·카메라 동작을 확인해야 한다. 단순 재시도나 풀 확대만으로 해결 판정하지 않는다.

남은 핵심 한계: 과거 최종 DMA -12 사례의 잔존 객체 소유자까지 소급 확정한 것은 아니다. 이번에 확인한 경계 결함이 현장 Swap 3GB나 모든 LMKD를 설명한다는 증거도 없다. 현장 Swap 원인은 계속 별도 미확정이다.

측정 품질: 두 trace는 각각 26,312/26,312개와 27,501/27,501개를 보존했다. 전체 alloc 반환 probe에는 각각 18/12회 누락, 두 번째 erase probe에는 1회 누락이 있었으나 대상 큰 요청은 각각 29/26회의 진입·반환을 모두 짝지었다. 경계 변수 probe의 누락은 없었다. 진단 probe 자체의 시간 영향과 시험 도중 다른 프로세스의 LMKD 가능성이 있어 성능·현장 발생률 통계로 사용하지 않는다. 마지막 복구 PID 21088에서 LLM/STT/TTS 초기화 및 음성 대기를 확인했고 추가 probe·시험 프로세스를 정리했다.

5. Swap 3GB: 현재 설명할 수 있는 것과 없는 것

현장 숫자의 정확한 의미와 추가 실측 (10월 19일)

플랫폼 Android 13의 system/memory/lmkd/lmkd.cpp는 kill 직전 /proc/<pid>/status의 VmRSS와 VmSwap을 읽어 to free … kB rss, … kB swap으로 기록한다(소스 99–100, 2951–2960, 2996–3004행). 커널 문서 kernel/msm-5.4/Documentation/filesystems/proc.txt 268–269행에 따르면 VmSwap은 익명 private 데이터의 Swap이며 shmem 객체의 Swap은 포함하지 않는다. 따라서 현장 표의 Swap 3,153.6~3,406.1 MB가 이 LMKD 로그에서 계산됐다면, 이는 그 순간 종료 대상 프로세스에 계상된 익명 페이지의 비압축 논리 크기다. zram 전체 용량, NPU 메모리 크기, 압축 후 실제 RAM 사용량, 또는 종료 후 별도 프로세스에 남는 누적량을 뜻하지 않는다. 현장 표를 만든 파서 원본은 아직 대조하지 못했으므로 LMKD 로그에서 계산됐다면이라는 조건을 유지한다. 다른 현장 프로세스들의 Swap이 대체로 수십 MB인 반면 앱만 약 3GB였으므로, 공통 부팅 런타임보다 앱 고유의 익명 할당 수명을 우선 조사하는 것이 타당하다. 다만 할당자를 특정한 증거는 아니다.

현재 모델이 올라간 시험 보드의 프로세스 PID 21088에서 /proc/status와 smaps_rollup, 전체 smaps를 같은 시점에 수집했다. VmRSS 865,244 kB, RssAnon 786,420 kB, VmSwap 22,568 kB였고, smaps 합계 Swap은 22,756 kB, SwapPss는 673 kB였다. VmSwap과 smaps의 작은 차이는 순차 수집 중 페이지 상태가 변할 수 있기 때문이다. 가장 큰 RSS 영역은 Scudo secondary 578,200 kB(그 영역의 Swap 0), Scudo primary 132,668 kB(Swap 2,492 kB)였다. 현재의 Swap은 Dalvik/zygote 공유 매핑 등의 영향이 커 SwapPss가 작다. 이 한 시점의 구성으로 현장 3GB의 소유 영역까지 역산할 수 없다.

같은 시점 zram mm_stat은 원본 데이터 306,167,808바이트, 압축 데이터 78,130,748바이트, 실제 사용 82,386,944바이트였다. 이는 기기 전체 스왑 상태이며 프로세스별 수치가 아니다. 현장 3GB도 압축률과 공유 여부를 확인하기 전에는 3GB 물리 RAM을 반환했다고 표현하면 안 된다. 다음 현장 재현에서는 kill 직전 smaps의 VMA별 Swap/SwapPss, /proc/<pid>/status, zram mm_stat, LMKD 원문을 한 묶음으로 저장해야 CPU heap·Dalvik·공유 매핑 중 소유 영역을 판별할 수 있다.

재부팅 시나리오를 직접 시험: 부팅 압박은 재현, Swap 3GB는 미재현 (10월 19일)

왜 시험했나: 현장 10대의 동시기 발생과 전체 기기 재부팅 이력이 있어, 부팅 서비스·카메라·모델 초기화가 겹치면서 앱의 익명 메모리가 대량 Swap으로 이동했을 가능성을 확인했다. 동일 시험 보드를 두 차례 재부팅하고 앱 자동 시작, GenieDialog_create, LMKD 원문, 프로세스 RSS/Swap, smaps와 시스템 압박을 추적했다. 첫 재부팅의 초기 호스트 표본은 수집 명령의 인용 오류로 무효지만, 기기 logcat의 LMKD 원문은 보존됐다. 두 번째 재부팅은 명령을 고쳐 초기화 구간의 프로세스·VMA 표본을 확보했다.

현재 우선순위: 단순 재부팅만으로 현장 Swap 3GB가 생긴다는 설명은 이번 두 번의 시험에서 지지되지 않는다. 반면 재부팅 시 다른 서비스와 모델 로딩이 겹쳐 LMKD가 발생하고 앱이 여러 번 재초기화되는 경로는 실제로 확인했다. 현장 Swap이 LMKD의 VmSwap 값이라면 커널 정의상 익명 private 데이터이므로, 장시간 살아 있는 앱 고유 버퍼·allocator 보유 영역이 반복 작업과 지속 압박을 거쳐 Swap으로 이동하는 경우를 우선 의심한다. 이는 가설이며, 이 보드의 재부팅·반복 추론·압박 시험에서 3GB는 재현되지 않았다. 현장 배포본/모델, 장기 작업 패턴, kill 직전 VMA 자료 없이는 그 할당의 출처나 재부팅과의 인과관계를 확정할 수 없다.

같은 프로세스의 할당이 살아 있는 동안 사용 빈도가 낮은 CPU 페이지가 메모리 압박으로 Swap에 남을 수 있다. 초기화 완료나 압박 완화 자체가 해당 할당의 해제를 뜻하지 않는다. 재접근하면 일부 페이지가 RAM으로 돌아오고, 실제 할당 해제·unmap·프로세스 종료 등 수명 종료 시 회수된다. 프로세스가 죽은 뒤 새 프로세스에 과거 개인 Swap이 계속 누적된다는 설명은 맞지 않는다.

다만 이것은 가능한 메커니즘이다. 현장 3GB가 모델 초기화에서 생긴 뒤 살아남은 호스트 할당인지, 장시간 서비스 작업의 익명 버퍼인지, allocator가 보유한 영역인지 아직 특정하지 못했다. VmSwap만으로 공유 여부와 실제 zram 점유량도 알 수 없다. NPU 매핑 크기 1.7GiB가 곧 프로세스 Swap 3GB라는 해석도 증명되지 않았다.

강한 압박 시험에서는 카메라 LMKD 및 자동 재시작이 관측됐다. 복구 구간은 시험 드라이버 오류로 네이티브 종료와 앱 재시작이 겹쳤으므로, 그때의 ONDEVICE 재종료를 제품 정상 복구 시나리오의 재현 근거로 쓰지 않는다. 이후 LLM/STT/TTS 준비와 음성 대기 상태는 확인했다. 직접 네이티브 시험 프로세스는 보호된 oom 우선순위로 실행되어 제품 앱 생존성 비교에 쓸 수 없다.

6. RSS 800~1,400MB와 LMKD를 어떻게 설명하나

RSS는 모델 파일의 clean 페이지, STT/TTS 익명 메모리, 런타임·기타 버퍼 중 그 순간 RAM에 남아 있는 부분이다. clean 파일 페이지 회수, 익명 페이지 swap-out, 새로운 할당과 재접근에 따라 변한다. 프로세스 중요도는 LMKD의 종료 대상 선택에 영향을 주지만 중요도별 RSS 목표를 800/1,400MB로 직접 설정하는 것은 아니다.

초기화 시험에서는 모델 clean 파일 페이지 약 1,690.5MiB가 포함된 RSS 피크 약 2,078MiB도 관측했다. 따라서 낮은 RSS 한 번이 같은 기능을 늘 그 수준으로 유지할 수 있다는 증거는 아니다. 합성 후 TTS 회수는 평균·대기 부담을 줄일 후보지만, 초기화 피크 및 NPU 버퍼 부담까지 해결하지 않는다.

또한 LMKD는 MemAvailable 하나로 결정되지 않는다. 이전 별도 추적에서는 전체 free 약 1.22GiB에도 평가 대상 zone의 CMA 제외 free가 약 73MiB로 high watermark 약 100MiB보다 낮았다. 이 사례의 종료 대상은 SystemUI였고, 현장 ONDEVICE 10건의 동일 원인을 증명한 것은 아니다. 현장 원인은 kill reason·oom_adj·PSI·zone·Swap을 같은 시점에서 모아 판정해야 한다.

7. 현실적인 대응과 완료 기준

현장 10건은 제공된 사례이며 수집 기간은 1주다. 전체 약 2,000대의 정확한 관측 시간·분모·누락 정보가 없으므로 발생률로 환산하지 않았다. 시험 보드와 현장 A1_1.8.0 바이너리 동일성도 미확정이다.

Connections

• 시험별 상세 증거 및 기존 분석 전체
• 초기 LMKD/RSS/Swap 조사