오늘 이 글을 읽었습니다보다그러나 나는 인터럽트에 대한 주제를 전혀 이해하지 못하므로 지식이 있는 누군가가 과거에 이 데몬을 사용했던 이유와 현재 권장되는 이유를 설명한다면 좋을 것입니다.
답변1
내 거보다문제는 이것이 과거/현재, 현대 대 고대 제도의 문제가 아니라는 점이다. 이게 더 궁금한데시스템, 워크로드, 최적화하려는 항목에 대해 알고 있는 정보(대기 시간 대 처리량) 더 많이 알수록 도우미가 문제를 망치는 것을 덜 원하게 됩니다.확실하지 않다귀하의 시스템을 제어하고 귀하를 대신하여 결정을 내리십시오. (*1)
시작 시 인터럽트는 일반적으로 CPU 간에 균등하게(수 기준) 공유됩니다. (즉, 런타임에 발생하는 빈도와 핸들러가 완료되는 데 걸리는 CPU 시간에 관계없이). 일정과 작업량에 따라 원하지 않는 지연이 발생할 수 있습니다.
예를 들어, 2개의 PCI 사운드 카드가 있는데 둘 다 매우 제한된 버퍼(대기 시간을 줄이기 위해)를 사용하여 96KHz 샘플링 속도로 병렬로 사용되며 일부 USB-MIDI 하드웨어가 추가되었습니다. (*2)
이 경우, 나는 irq 공유를 피하기 위해 최선을 다했으며(다른 장치는 동일한 IRQ를 사용함) 3개의 연관된 irq(각 장치당 하나씩)가 동일한 CPU에 있는 것을 확실히 원하지 않습니다. 그리고 가능하다면 Ardor가 사용하는 CPU가 아닌... 단순히 이유는 다음과 같습니다.
- 둘 다 동일한 중요성을 갖기 때문에 IRQ 스레드는 동일한 실시간 우선순위로 실행되므로 다른 IRQ가 처리되는 동안 발생하는 모든 인터럽트 처리가 지연되어 대기 시간이 늘어납니다(더 나쁘지는 않더라도): XRUNS (버퍼 오버플로로 인해 샘플이 폐기되었습니다.)
- 이러한 인터럽트를 처리하는 데 필요한 코드 및 데이터 구조는 프로세서의 데이터 및 명령어 캐시에 있을 가능성이 가장 낮으며, 이로 인해 인터럽트가 처리될 때마다 추가 대기 시간이 발생합니다.
irqbalance 데몬은 다음을 수행할 수 있습니다.아마도얼마 후, 어느 시점에서 초기 구성이 최적이 아니라는 사실이 발견되어 (런타임에) IRQ 핀을 (비용이 많이 드는) 재구성하기로 결정했습니다(아마도 미디 키보드 사용을 중단하면 유턴할까요?) 흠. .. 가능한!
하지만 이 모든 것을 염두에 두고 나 자신은 이 3개의 IRQ 각각에 대한 CPU를 단번에 분리하고 4번째 IRQ가 다른 모든 것을 처리하도록 할 것입니다. (물론 더 이상은 할 수 없습니다... 저는 코어 II를 실행하고 있습니다 ;-) 그리고... irqbalance 데몬: HandsOFF, 제가 뭘 하는지 알아요!
대신, irqbalance 데몬에 대한 동일한 결정으로 이어지므로, 내가 CPU 바인딩 작업의 처리량에만 관심이 있다는 것을 알았다면 모든 irq를 하나로 고정해야 합니다.가정CPU를 사용하고 다른 모든 CPU가 간섭 없이 작업 부하를 공유하도록 합니다.
그리고 자신의 시스템이 모든 일을 더 잘 할 수 있기를 기대하는 경험이 부족한 소위 "일반 데스크톱 사용자"도 있습니다.믿다낮은 수준의 소프트웨어 고려 사항에 대해 걱정할 필요 없이 최상의 런타임 조건을 제공합니다. (무례한 의도는 없습니다. 저는 때때로 (그러나 드물게) 그런 일이 발생합니다.)
이 경우 irqbalance 데몬을 실행하면때때로(그리고 비용이 많이 들기 때문에) 대기 시간을 줄이는 데 도움이 되지만 확실히확실하지 않다방법.
어쨌든, 내가 8코어 시스템에서 48Kz/60fps 비디오를 보고 이메일에 답장할 때 누가 눈치챌까요? 그건 그렇고, 이것이 아마도 irqbalance 데몬의 관심을 현대성과 연관시킬 수 있는 이유일 것입니다. 현대화될수록 더 많은 CPU를 보유하고 주파수가 높아질수록 CPU 고정에 대해 걱정할 필요가 줄어듭니다.
면책조항: (*3)
이제 IRQ 관리에 대해 좀 더 기술적으로 살펴보겠습니다.
Linux에서는 IRQ(또는 MSI)가 발생할 때 필요한 작업을 수행하기 위해 인터럽트를 처리하는 두 가지 방법이 있습니다.
오래된 전통적인 방식: IRQ 처리기의 일부로 모든 작업을 커널 공간에 구현합니다. 이는 가능한 최고의 처리량을 달성하지만 실행 중인 작업(매우 중요할 수 있음)을 불편하게 중단하고 처리 전반에 걸쳐 다른, 아마도 더 중요한 IRQ를 마스크합니다.
라이브 시스템에서는 확실히 이것을 원하지 않습니다.스레드 IRQ 방법: IRQ 처리기의 일부로 최소한의 작업을 수행합니다. 구현해야 할 것은 모든 인터럽트를 마스크하고 대부분의 작업을 SCHED_RR(우선순위가 가장 높을 때)을 예약하는 커널 스레드가 수행하도록 두는 것입니다.
물론 최소한 2개의 추가 컨텍스트 전환이 필요하므로 처리 시간이 늘어나지만, 이는 물론 상대적 우선순위(작업 간, IRQ 처리기 간, 작업과 IRQ 처리기 시간 간)가 실제로 중요한 실시간 시스템에 선호되는 방법입니다. 중요한.
이 스레드 IRQ 컨텍스트에서 irq 스레드는 기본적으로 IRQ를 처리하는 CPU에 고정됩니다. 그러나 런타임 시 로드 고려 사항에 따라 스케줄러는 유휴 시간이 있는 경우 다른 CPU에서 커널 스레드를 다시 예약하기로 결정할 수 있습니다. (*4)
따라서 2020년 초부터 스레드 irq 컨텍스트에서, 일부 데몬이 IRQ 처리기를 수정하도록(실시간으로, 비용이 많이 드는) 것은 분명히 (객관적으로) 비생산적입니다. 즉각적인 작업량 공유를 고려하여 가장 좋은 것이 무엇인지 스케줄러가 결정하게 하십시오!
*1: GPS를 생각해보세요. 우회전하세요! 해협에서! 글쎄, 돌아서!
*2: 일반적인 라이브 공연 DAW(적어도 내 :-P)
*3: 이 답변은 의견을 바탕으로 이해될 수 있습니다. 나는 런타임에 시스템을 구성하는 것을 싫어한다는 사실을 솔직하게 숨기지 않을 것입니다. 그들의 장난이 내 뜻과 일치하는 척한다면 나는 그들을 더욱 미워한다.
*4: 이는 2020년 초부터 가능했습니다.존 게리의 패치.
답변2
irqbalance정기점검/proc/인터럽트어떤 CPU/코어가 어떤 인터럽트를 처리하는지 확인하고 다음 인터페이스를 사용하여 인터럽트 처리를 균등하게 분배하십시오./프로세스/인터럽트. 이는 인터럽트 처리 시 CPU 바인딩 병목 현상이 발생할 때 대기 시간을 줄이고 성능을 향상시키는 데 도움이 됩니다.
스토리지, 네트워크 장치 또는 하드웨어 타이머와 같은 장치는 CPU에 인터럽트 신호를 보냅니다. 예를 들어, 패킷이 도착하면 NIC(네트워크 인터페이스 컨트롤러)가 인터럽트를 트리거하여 CPU가 처리할 수 있도록 이에 대해 알릴 수 있습니다. 거의 모든 하드웨어는 이런 방식으로 CPU와 통신합니다.
불행하게도 일부 인터럽트는 이동할 수 없으므로 그 중 하나가 높은 CPU 부하를 유발하는 경우 수행할 수 있는 작업이 많지 않습니다. 또 다른 제한 사항은 모든 커널 드라이버가 인터럽트 핸들러를 지원하더라도 인터럽트 핸들러를 다른 CPU/코어로 오프로드할 수 없다는 것입니다. 이 문제를 해결하려면 다음을 추가해 보세요.스레드 인터럽트시작 시 커널 매개변수.