ALLOCATED는 누적 호출 횟수가 아닙니다
crash의 kmem -s에서 ALLOCATED는 해당 덤프 시점에 할당 상태인 캐시 객체 수로 읽습니다. 한 객체를 반복 할당·해제한 횟수가 아닙니다. 객체 크기와의 곱은 명목 객체 점유 계산이며 slab의 여유 공간·관리 정보까지 포함한 전체 비용과 구분합니다.
공개 사례는 조사 출발점이지 원인 확정이 아닙니다
Austin Kim의 공개 기사는 Raspberry Pi 4의 Linux 5.15.74-v8+ 덤프에서 kmalloc-256의 ALLOCATED=12,438,464를 제시합니다. 그 값에 256을 곱하면 약 2.97 GiB입니다. 여기서는 저자가 공개한 출력에 대한 산술로만 사용합니다. 원본 vmcore·동일 빌드 심벌로 수치를 재현한 결과가 아닙니다.
큰 점유는 조사할 이유지만 한 시점만으로 계속 증가하는 누수나 해제를 놓친 모듈을 확정하지 않습니다. OOM 스택에서 마지막 할당을 시도한 경로와 그전에 객체를 보유한 주체도 같다고 단정할 수 없습니다.
값 검색 결과는 소유자 목록이 아닙니다
search에 캐시 주소 값을 넣으면 선택한 메모리 영역에서 그 값이 나타나는 위치를 찾습니다. 일치한 값이 모두 유효한 참조인지, 그 참조가 할당 객체를 소유하는지, 어느 호출에서 만들어졌는지는 추가 해석이 필요합니다. 출력 행 수를 객체 수·누수 횟수·할당 스택 수로 바꾸지 않습니다.
kmem: 어느 캐시의 점유가 큰가
search: 어떤 주소에 같은 값이 나타나는가
추가 증거: 객체 타입·참조 수명·반복 관찰·할당과 해제 경로
심벌·덤프 범위·사전 추적을 함께 남깁니다
분석한 커널 빌드와 vmlinux·module 심벌을 맞추고 dump 필터로 빠진 영역을 기록합니다. 작업량과 시간에 따른 점유 변화, 종료 경로에서 참조가 줄어드는지 확인합니다. SLUB의 U 추적 같은 기능은 지원·사전 활성화 조건과 비용이 있으며 이미 사라진 과거 할당 이력을 나중에 켜서 복원하지 못합니다.
기존 SLUB 글의 Linux 6.18.37 구현과 위 5.15 사례는 서로 다른 버전입니다. 이 글은 명령의 해석 경계를 설명하며 덤프 실행, 원본 표지 이미지 검증, 특정 누수 수정 완료를 주장하지 않습니다.