리눅스 타이머 인터럽트

리눅스 타이머 인터럽트

Linux 커널에 관해 두 가지 질문이 있습니다. 구체적으로, 타이머 인터럽트로 Linux가 수행하는 작업을 정확히 아는 사람이 있습니까? 이에 대한 문서가 있습니까? 커널을 빌드할 때 CONFIG_HZ 설정을 변경하면 어떤 영향이 있나요?

미리 감사드립니다!

답변1

Linux 타이머 인터럽트 핸들러는 그렇게 많은 작업을 수행하지 않습니다.곧장. x86의 경우 기본 PIT/HPET 타이머 인터럽트 핸들러를 찾을 수 있습니다.존재하다arch/x86/kernel/time.c:

static irqreturn_t timer_interrupt(int irq, void *dev_id)
{
    global_clock_event->event_handler(global_clock_event);
    return IRQ_HANDLED;
}

그러면 전역 시계 이벤트에 대한 이벤트 핸들러가 호출됩니다.tick_handler_periodic기본적으로,지피 카운터 업데이트, 전역 부하를 계산하고 시간이 추적되는 다른 위치를 업데이트합니다.

인터럽트 발생의 부작용으로,__schedule결국 호출될 수 있으므로 타이머 인터럽트로 인해 작업 전환이 발생할 수도 있습니다(다른 인터럽트와 마찬가지로).

변화구성_HZ타이머 인터럽트 주기를 변경합니다. 증가는 HZ더 자주 발생하므로 타이머와 관련된 오버헤드가 더 많지만 작업 예약이 잠시 기다릴 기회가 적다는 것을 의미합니다(따라서 상호 작용이 향상됨). 감소는 HZ덜 자주 발생하므로 관련 오버헤드가 적다는 것을 의미합니다. 타이머 사용 타이머와 관련된 오버헤드는 적지만 작업이 예약되기를 기다리는 위험이 더 높습니다(따라서 대화형 응답성을 희생시키면서 처리량이 증가합니다). 항상 그렇듯이 최상의 절충안은 특정 워크로드에 따라 다릅니다. 어쨌든 CONFIG_HZ이제는 일정 측면에서 관련성이 떨어집니다.Linux CPU 스케줄러에서 사용하는 시간 조각 길이를 변경하는 방법은 무엇입니까?

당신은 또한 볼 수 있습니다Linux에서 인터럽트를 처리하는 방법은 무엇입니까?

답변2

리눅스가 하는 일존재하다타이머 인터럽트?

나는 이것이 중간 조치를 요구한다고 생각합니다.

다음에서 복사했습니다 __schedule().

 *   3. Wakeups don't really cause entry into schedule(). They add a
 *      task to the run-queue and that's it.
 *
 *      Now, if the new task added to the run-queue preempts the current
 *      task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
 *      called on the nearest possible occasion:

시작하기에 좋은 곳입니다. 문서가 잘 정리되어 있습니다. 이것이 긴 이야기의 시작이다. "깨어나다"란 무엇입니까? R 및 S 상태와 관련이 있습니까? 그리고 차단?

나는 SK의 답변과 링크 중 하나에 대해 약간의 이의가 있습니다. HZ가 "더 이상 중요하지 않음"에 대한 것입니다.

어쩌면 과거에 약간의 혼란이 있었기 때문일 수도 있습니다. 100HZ에서 1000HZ로 그리고 다시 300HZ로 과도하게 수정하여 동시에 "멀티미디어"에 적응해야 했습니다(HPET Origins 2005: "멀티미디어 타이머"를 생각해 보세요).

4개 이상의 코어를 가질 수 있지만 실제로는 중요하지 않습니다. 그러나 이는 "서버"로 수행하려는 작업에 따라 여전히 중요합니다. 이러한 대기 시간/처리량 균형은 부하가 심한 경우 중요할 수 있습니다.

타이머 인터럽트에서 스케줄링이 수행되지 않으면 이러한 "다른" 인터럽트에서 스케줄링이 수행됩니다.

HZ를 구성할 수 없는 이유는 무엇입니까(시작 시 또는 런타임 시에도)?

관련 정보