먼저 어느 두 시각을 뺐는지 확인합니다
BCC v0.35.0 offcputime.py는 finish_task_switch에서 이전 태스크의 시각을 저장하고, 그 태스크가 다시 실행될 때 차이를 집계합니다. 기본 state 필터는 모든 상태를 통과시켜 실행 가능 상태로 밀려난 시간도 포함할 수 있습니다. --state 0은 실행 가능 상태를 고르는 조건이지 잠든 태스크만 고르는 조건이 아닙니다.
따라서 집계값을 그대로 I/O 대기 시간이나 깨워질 때까지의 시간으로 이름 붙이지 않습니다. 잠든 태스크라도 깨워진 뒤 실제 CPU를 받을 때까지의 지연이 포함될 수 있습니다. 대상 태스크·상태 필터·최소 및 최대 시간 조건을 결과와 함께 남깁니다.
깨움을 시도한 문맥은 원인 추적의 단서입니다
같은 버전의 offwaketime.py는 try_to_wake_up 진입에서 대상 PID에 깨움 호출 문맥을 기록하고, 다음 실행 때 태스크의 off-CPU 구간과 연결합니다. 반환값으로 성공을 검증하는 훅은 아니므로, 이 연결만으로 모든 깨움의 성공이나 최종 원인을 증명하지는 않습니다.
2016년 off-wake 설명처럼 인터럽트 문맥에서 깨움이 일어날 수도 있고, 앞선 의존 관계가 여러 단계일 수도 있습니다. 화면의 waker 이름 하나를 책임 프로세스로 단정하지 말고, 스택·요청 식별자·다른 사건 기록과 대조합니다.
불꽃 그래프의 폭은 시간축이 아닙니다
off-CPU 불꽃 그래프는 스택별로 합산한 지속 시간을 폭으로 나타냅니다. 가로 위치가 사건 순서는 아니며 여러 태스크의 합은 관찰한 실제 시간보다 클 수 있습니다. CPU 표본 수를 폭으로 쓰는 그래프와도 단위가 다릅니다.
2015년 perf 기반 예시와 이후 BPF 집계 방식은 수집 비용이 같지 않습니다. 스택 누락·버퍼 손실·선택 조건과 관찰 자체의 영향을 확인한 뒤 비교합니다. 여기서는 추적기를 실행하거나 특정 장비의 병목을 측정하지 않았습니다.
- 태스크 구간
실행에서 빠진 시점부터 다시 실행될 때까지
- 깨움 문맥
기록된 호출과 태스크를 연결
- 원인 검증
스택·필터·사건 순서를 따로 대조