/proc/interrupts다양한 CPU 격리(IRQ 및 프로세스) 구성에서 지정된 워크로드를 실행하는 동안 로컬 타이머 인터럽트 수에 대해 보고된 값(총계)에서 큰 차이가 관찰 되지 않았습니다. /proc/stats로컬 타이머 인터럽트 수가 약 .는 20%이다.
답변: 내가 아는 한, current_clocksource = hpet일 때 로컬 타이머 인터럽트는 비교기에 의해 생성되고, 비교기는 = 비교(>= 대신) 이후에 인터럽트를 트리거합니다. 이로 인해 "잊음"으로 인해 인터럽트가 트리거됩니다. 과부하가 걸렸습니다. 현재 시간이 목표 값을 초과했기 때문입니다. 이를 통해 주어진 워크로드에 대해 LOC가 많을수록 좋다는 결론을 내렸습니다. (낙하 사고 감소)
B. 내가 아는 한, 시스템은 이벤트를 "결합"하고 Timerslack_ns 시간 내에 발생하는 여러 이벤트에 대한 인터럽트를 트리거할 수 있습니다. 이것으로부터 나는 주어진 워크로드와 주어진 timeslack_ns에 대해 LOC가 적을수록 좋다는 결론을 내렸습니다. (시스템에 더 많은 병합 기회 제공)
내 지식이 시대에 뒤떨어졌거나 제대로 적용되지 않고 있나요? (리눅스 5.4에서 실행)
"잊어버린" 타이머 이벤트 수를 결정하는 방법은 무엇입니까?
"병합된" 타이머 이벤트 수를 결정하는 방법은 무엇입니까?
마지막으로, 동일한 작업 부하를 고려하고 전력 소비 고려 사항을 무시하고 대기 시간과 처리량만 고려합니다(예, 이것이 다소 모순적이라는 것을 알고 있으므로 CPU 격리 테스트를 수행한 이유입니다). 어떤 구성을 선호해야 합니까? 총 (대형) LOC 인터럽트 수와 훨씬 적은 인터럽트를 제공하는 것은 무엇입니까?
같은 상황에서 비활성화를 시도했지만
kernel.timer_migration중요한 변화를 발견하지 못했습니다. 나는 이것이 내 IRQ와 작업이 적절하게 마샬링되었다는 증거라고 생각합니다(타이머 마이그레이션 필요 없음 => 스레드 마이그레이션 필요 없음). 그러나 내가 틀렸을 수도 있고 올바른 데이터 세트를 읽지 못할 수도 있습니다.