Linux Softirq 및 작업 대기열의 역할은 무엇입니까

Linux의 소프트 인터럽트 및 작업 대기열 기능은 인터럽트 처리를 구현하는 것입니다. 소프트 인터럽트와 작업 대기열은 상위 및 하위 인터럽트 메커니즘의 하위 절반 구현 메커니즘입니다. 소프트 인터럽트는 휴면, 차단 또는 프로세스 간 전환이 불가능하며 하드웨어 인터럽트에 의해서만 중단될 수 있습니다. 반면 작업 대기열은 휴면 또는 차단될 수 있으며 여러 프로세스 간에 전환하여 여러 작업을 완료할 수 있습니다.

이 튜토리얼의 운영 환경: linux5.9.8 시스템, Dell G3 컴퓨터.

Linux의 소프트 인터럽트 및 작업 대기열 기능은 인터럽트 처리를 구현하는 것입니다.

1. 인터럽트 개념

인터럽트는 CPU가 정상적으로 작동하는 동안 내부 및 외부 이벤트 또는 프로그램 사전 예약 이벤트로 인해 실행 중인 프로그램을 일시적으로 중지하고 대신 내부 또는 외부 이벤트 또는 사전에 설정된 이벤트 서비스를 수행한 후 서비스가 완료된 후 일시적으로 중단된 프로그램을 계속 실행하기 위해 복귀합니다. Linux는 일반적으로 외부 인터럽트(하드웨어 인터럽트라고도 함)와 내부 인터럽트(예외라고도 함)로 구분됩니다.

실제 주소 모드에서 CPU는 메모리의 0부터 시작하는 1KB 공간을 인터럽트 벡터 테이블로 사용합니다. 테이블의 각 항목은 4바이트를 차지합니다. 그러나 보호 모드에서는 이러한 4바이트 항목으로 구성된 인터럽트 벡터 테이블이 실제 요구 사항을 충족하지 못하므로 모드 전환 및 오프셋을 반영한 정보를 기반으로 인터럽트 벡터 테이블 항목을 8바이트로 구성합니다. , 인터럽트 벡터 테이블은 IDT(인터럽트 설명자 테이블)라고도 합니다. 인터럽트 디스크립터 테이블을 기술하는데 사용되는 레지스터(IDTR)는 인터럽트 디스크립터 테이블의 시작 주소를 저장하기 위해 CPU에 추가된다.

2. Linux 인터럽트 처리

2.1 시스템 인터럽트 번호

위의 인터럽트 정의에서 총 256개의 인터럽트 벡터 항목이 시스템 인터럽트 벡터 테이블에 저장될 수 있음을 알 수 있습니다. IDT 기호에 포함된 256개의 인터럽트 설명입니다(256개의 인터럽트 벡터에 해당).

　인터럽트 벡터 0-31은 Intel에서 비정상적인 이벤트를 처리하기 위해 예약되어 있으며 다른 목적으로 사용할 수 없습니다. 인터럽트 벡터 번호 0-31의 경우 운영 체제는 예외 핸들러만 제공하면 됩니다. 예외가 발생하면 프로세서는 자동으로 해당 핸들러의 항목으로 제어를 전송하고 실제로 해당 핸들러를 실행합니다. 예외를 처리하는 인터럽트 벡터, Linux 2.6 버전은 인터럽트 벡터 번호 0-17에 대한 핸들러만 제공합니다. 해당 핸들러에 대해서는 다음 표, 인터럽트 벡터 및 예외 이벤트 대응 표를 참조하십시오. 인터럽트 벡터 번호 17-31은 비어 있고 사용되지 않습니다.

일반 보호 예외 _protection 14페이지 예외Page_fault15(인텔 예약)Spurious_interrupt_bug16보조 프로세서 오류Coprocessor_error 17 정렬 확인이 중단되었습니다Alignment_check

인터럽트 벡터 번호	예외 이벤트	Linux 핸들러
0	분할 오류	pide_error
1	DebugException	Debug
2	NMI 인터럽트	Nmi
3	싱글바이트, 정수 3	Int3
4	Overflow	Overflow
5	경계 모니터링 중단	Bounds
6	잘못된 opcode	Invalid_op
7	Device_not_available	Device_not_available
8	Double_fault	Double_fault
9	보조 프로세서 세그먼트 오버런	Coprocessor_segment_overrun
10	잘못된 TSS	Incalid_tss
11	Miss ing 세그먼트 인터럽트	Segment_not_present
인터럽트 벡터 0~31은 예약되어 있어 총 224개의 인터럽트 벡터 32~255를 사용할 수 있습니다. 224개의 인터럽트 벡터는 어떻게 할당됩니까? Linux 2.6 버전에서는 시스템 호출 일반 항목으로 사용되는 0x80(SYSCALL_VECTOR)을 제외하고 나머지는 프로그래밍 가능한 인터럽트 컨트롤러 8259A의 15irq를 포함하여 외부 하드웨어 인터럽트 소스에 사용됩니다. CONFIG_X86_IO_APIC가 정의되지 않은 경우 나머지 223개(0x80 제외) 인터럽트 벡터 중 32번째부터 시작하는 15개만 사용되고 나머지 208개는 비어 있습니다. 　2.2 인터럽트 요청 　2.2.1 인터럽트 요청 개요 해당 인터럽트입니다. 　장치는 해당 인터럽트 라인을 통해 인터럽트 컨트롤러에 하이 레벨을 보내 인터럽트 신호를 생성하고, 운영 체제는 인터럽트 컨트롤러의 상태 비트에서 해당 인터럽트 라인에서 생성된 인터럽트를 얻습니다. 그리고 장치가 특정 인터럽트 라인을 제어할 수 있는 경우에만 이 인터럽트 라인에 신호를 보낼 수 있습니다. 또한 요즘에는 주변 장치가 점점 더 많아지기 때문에 인터럽트 라인은 매우 귀중한 리소스이며 일대일 매핑이 불가능합니다. 따라서 인터럽트 라인을 사용하기 전에 해당 인터럽트 라인을 신청해야 합니다. 공유 인터럽트 방식을 사용하든 배타적 인터럽트를 사용하든 관계없이 응용 프로세스는 먼저 모든 인터럽트 라인을 스캔하여 다른 인터럽트 라인이 점유되지 않은 라인을 찾아내고 그 중 하나를 장치의 IRQ로 선택합니다. 둘째, 인터럽트 적용 기능을 통해 해당 IRQ를 적용한다. 마지막으로 적용 결과에 따라 인터럽트를 실행할 수 있는지 확인합니다. 　　2.2.2 인터럽트 관련 구조 　 인터럽트의 핵심 처리 데이터 구조는 irq_desc로, 인터럽트 라인을 완벽하게 기술한 리눅스 2.6의 소스코드는 다음과 같다. DIRQ_DESC include/Linux/IRQ.H의 정의 R /** * struct irq_desc - interrupt descriptor * * @handle_irq: highlevel irq-events handler [if NULL, __do_IRQ()] * @chip: low level interrupt hardware access * @msi_desc: MSI descriptor * @handler_data: per-IRQ data for the irq_chip methods * @chip_data: platform-specific per-chip private data for the chip * methods, to allow shared chip implementations * @action: the irq action chain * @status: status information * @depth: disable-depth, for nested irq_disable() calls * @wake_depth: enable depth, for multiple set_irq_wake() callers * @irq_count: stats field to detect stalled irqs * @irqs_unhandled: stats field for spurious unhandled interrupts * @lock: locking for SMP * @affinity: IRQ affinity on SMP * @cpu: cpu index useful for balancing * @pending_mask: pending rebalanced interrupts * @dir: /proc/irq/ procfs entry * @affinity_entry: /proc/irq/smp_affinity procfs entry on SMP * @name: flow handler name for /proc/interrupts output */struct irq_desc { irq_flow_handler_t handle_irq; struct irq_chip *chip; struct msi_desc *msi_desc; void *handler_data; void *chip_data; struct irqaction *action; /* IRQ action list */ unsigned int status; /* IRQ status */ unsigned int depth; /* nested irq disables */ unsigned int wake_depth; /* nested wake enables */ unsigned int irq_count; /* For detecting broken IRQs */ unsigned int irqs_unhandled; spinlock_t lock; #ifdef CONFIG_SMP cpumask_t affinity; unsigned int cpu;#endif#if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE) cpumask_t pending_mask;#endif#ifdef CONFIG_PROC_FS struct proc_dir_entry *dir;#endif const char *name; } ____cacheline_internodealigned_in_smp; E IRQ_DESC 다음과 같습니다. include/linux/interrupt.h에 정의됨 인터럽트 동작 구조: struct irqaction struct irqaction { irq_handler_t handler; unsigned long flags; cpumask_t mask; const char *name; void *dev_id; struct irqaction *next; int irq; struct proc_dir_entry *dir; }; 정의됨 include/linux: irq_chip 칩 관련 처리 함수 모음 /** * struct irq_chip - hardware interrupt chip descriptor * * @name: name for /proc/interrupts * @startup: start up the interrupt (defaults to ->enable if NULL) * @shutdown: shut down the interrupt (defaults to ->disable if NULL) * @enable: enable the interrupt (defaults to chip->unmask if NULL) * @disable: disable the interrupt (defaults to chip->mask if NULL) * @ack: start of a new interrupt * @mask: mask an interrupt source * @mask_ack: ack and mask an interrupt source * @unmask: unmask an interrupt source * @eoi: end of interrupt - chip level * @end: end of interrupt - flow level * @set_affinity: set the CPU affinity on SMP machines * @retrigger: resend an IRQ to the CPU * @set_type: set the flow type (IRQ_TYPE_LEVEL/etc.) of an IRQ * @set_wake: enable/disable power-management wake-on of an IRQ * * @release: release function solely used by UML * @typename: obsoleted by name, kept as migration helper */struct irq_chip { const char *name; unsigned int (*startup)(unsigned int irq);　　//中断开始 void (*shutdown)(unsigned int irq);　　　　//中断关闭 void (*enable)(unsigned int irq);　　　　　　//中断使能 void (*disable)(unsigned int irq);　　　　//中断禁用 void (*ack)(unsigned int irq); void (*mask)(unsigned int irq); void (*mask_ack)(unsigned int irq); void (*unmask)(unsigned int irq); void (*eoi)(unsigned int irq); void (*end)(unsigned int irq); void (*set_affinity)(unsigned int irq, cpumask_t dest); int (*retrigger)(unsigned int irq); int (*set_type)(unsigned int irq, unsigned int flow_type); int (*set_wake)(unsigned int irq, unsigned int on); /* Currently used only by UML, might disappear one day.*/#ifdef CONFIG_IRQ_RELEASE_METHOD void (*release)(unsigned int irq, void *dev_id);#endif /* * For compatibility, ->typename is copied into ->name. * Will disappear. */ const char *typename; }; 2.2.3 인터럽트 요청 구현 상하반 메커니즘 우리는 인터럽트 핸들러를 빠르게 실행하기를 희망하며, 더 많은 작업을 완료하기를 원합니다. 이 두 가지 목표는 서로를 제한하고 ——상부 메커니즘 을 해결하는 방법입니다. 인터럽트 처리를 절반으로 줄였습니다. 인터럽트 핸들러는 상위 부분입니다 - 인터럽트를 수락하고 즉시 실행을 시작하지만 엄격한 시간 제한이 있는 작업만 수행할 수 있습니다. 나중에 완료할 수 있는 작업은 하반기로 연기한 후 적절한 시기에 단말기에서 하반기를 실행합니다. 전반부는 간단하고 빠르며 실행 중 일부 또는 모든 중단을 비활성화 합니다. 　후반부는 나중에 실행되며 실행 중에 모든 인터럽트에 응답할 수 있습니다. 이러한 설계는 인터럽트 보호 상태의 시스템을 최대한 짧게 만들어 시스템의 응답성을 향상시킬 수 있습니다. 위쪽 절반에는 인터럽트 처리기 메커니즘만 있고 아래쪽에는 소프트 인터럽트 구현, tasklet 구현 및 작업 대기열 구현이 있습니다. 우리는 이 두 부분을 설명하기 위해 네트워크 카드를 사용합니다. 네트워크 카드는 데이터 패킷을 수신하면 커널에 알리고 인터럽트를 발생시킵니다. 소위 전반은 지연으로 인한 손실을 방지하기 위해 데이터 패킷을 제때에 메모리로 읽어들이는 것입니다. 메모리를 읽은 후에는 이러한 데이터 처리가 더 이상 긴급하지 않습니다. 이때 커널은 인터럽트 이전에 실행 중인 프로그램을 실행할 수 있으며 네트워크 데이터 패킷 처리는 하위 절반에 맡겨집니다. 상하 분할의 원리 　　1) 시간에 민감한 작업이라면 인터럽트 핸들러에 넣어 실행하세요. 　2) 작업이 하드웨어와 관련된 경우 실행을 위해 인터럽트 핸들러에 넣습니다. 　3) 작업이 다른 인터럽트에 의해 중단되지 않도록 하려면 인터럽트에 넣습니다. handler Execution; 　　4) 다른 모든 작업은 아래쪽에 배치하여 실행하는 것을 고려하세요. 하반부 구현 메커니즘의 소프트 인터럽트 하위 메커니즘의 대표적인 것으로 소프트 인터럽트는 SMP(share memory processor)의 출현과 함께 등장했으며, 또한 tasklet구현의 기초(tasklet실제로는 소프트 인터럽트를 기반으로 특정 메커니즘을 추가합니다). Softirq는 일반적으로 "deferrable function"에 대한 일반적인 용어이며 때로는 tasklet을 포함합니다(독자는 tasklet을 접할 때 상황에 따라 포함 여부를 추론해야 합니다). 이는 위에서 제안한 상위 절반과 하위 절반 간의 구분을 충족해야 시간에 민감하지 않은 작업을 연기할 수 있어야 하기 때문에 나타납니다. 소프트 인터럽트는 인터럽트 핸들러에 의해 남겨진 나머지 작업을 실행하고 병렬 실행이 가능합니다. 여러 개의 CPU를 사용하면 전체 시스템 효율성이 높아집니다. 그 기능은 다음과 같습니다: a) 생성된 후에는 즉시 실행될 수 없으며 실행되기 전에 커널 스케줄링을 기다려야 합니다. 실행. 소프트 인터럽트는 스스로 인터럽트할 수 없고 하드웨어 인터럽트에 의해서만 인터럽트할 수 있습니다(상위 부분). 　b)은 여러 CPU(동일한 유형이라도)에서 동시에 실행할 수 있습니다. 따라서 소프트 인터럽트는 재진입 기능(여러 CPU이 동시에 작동할 수 있도록 허용)으로 설계되어야 하므로 데이터 구조를 보호하기 위해 스핀 잠금도 사용해야 합니다. 구현 메커니즘 tasklet의 하반부 Tasklet은 소프트 인터럽트를 통해 구현되므로 그 자체도 소프트 인터럽트입니다. 소프트 인터럽트는 폴링 방식으로 처리됩니다. 마지막 유형의 인터럽트인 경우 해당 처리 기능이 최종적으로 실행되기 전에 모든 인터럽트 유형을 순환해야 합니다. 분명히 폴링의 효율성을 보장하기 위해 개발자는 인터럽트 수를 32로 제한했습니다. 　인터럽트 처리 횟수를 늘리고 처리 효율성을 높이기 위해 tasklet 메커니즘이 만들어졌습니다. 　 Tasklet은 미분화된 대기열 메커니즘을 채택하고 중단이 있을 때만 실행되므로 순환 테이블 조회의 어려움이 사라집니다. Tasklet새로운 메커니즘으로서 분명히 더 많은 장점을 가질 수 있습니다. 이때 SMP가 점점 인기를 얻고 있었기 때문에 동일한 종류의 인터럽트가 하나의 cpu에서만 실행될 수 있도록 SMP 메커니즘이 tasklet에 추가되었습니다. 소프트 인터럽트 시대에는 분명히 그러한 고려 사항이 없었습니다. 따라서 동일한 소프트 인터럽트가 두 개의 cpu에서 동시에 실행될 수 있으며 이로 인해 충돌이 발생할 수 있습니다. tasklet의 장점 요약: 　 (1 ) 유형 수에는 제한이 없습니다. 　　(2 ) 효율성이 높으며 테이블 조회를 반복할 필요가 없습니다. 　 (3) SMP 메커니즘을 지원합니다. 기능은 다음과 같습니다: ) 특정 유형의 tasklet 은 하나의 CPU에서만 실행할 수 있으며 병렬로 실행할 수 없고 직렬로만 실행할 수 있습니다. 　2) 다양한 유형의 여러 tasklets을 여러 CPU에서 병렬로 실행할 수 있습니다. 　3) 소프트 인터럽트는 정적으로 할당되며 커널이 컴파일된 후에는 변경할 수 없습니다. 하지만 tasklet은 훨씬 더 유연하고 런타임에 변경될 수 있습니다(예: 모듈 추가 시). 구현 메커니즘의 하반부 - 작업 대기열 위에서 소개한 지연 가능 함수는 인터럽트 컨텍스트에서 실행됩니다(소프트 인터럽트의 체크포인트 중 하나는 do_IRQexit 시간입니다). 몇 가지 문제가 발생했습니다. 소프트 인터럽트는 잠자거나 차단할 수 없습니다. 인터럽트 컨텍스트는 커널 상태이고 프로세스 전환이 없기 때문에 소프트 인터럽트가 슬립 상태에 놓이거나 차단되면 이 상태를 종료할 수 없어 전체 커널이 정지됩니다. 그러나 차단 기능은 인터럽트 컨텍스트에서 구현될 수 없으며 디스크 데이터 블록에 액세스하는 기능과 같은 프로세스 컨텍스트에서 실행되어야 합니다. 따라서 Softirq를 사용하여 차단 기능을 구현할 수 없습니다. 그러나 그들은 종종 연기 가능한 속성을 가지고 있습니다. 위에서 소개한 지연 가능 함수는 인터럽트 컨텍스트에서 실행되는데, 이로 인해 일시 중단될 수 없음을 나타내는 몇 가지 문제가 발생합니다. 이는 소프트 인터럽트가 잠자거나 차단될 수 없다는 것을 의미합니다. 그 이유는 인터럽트 컨텍스트가 외부에 있기 때문입니다. 커널 상태에는 프로세스 전환이 없으므로 소프트 인터럽트가 절전 모드로 전환되거나 차단되면 이 상태를 종료할 수 없어 전체 커널이 정지됩니다. 따라서 Softirq를 사용하여 차단 기능을 구현할 수 없습니다. 그러나 그들은 종종 연기 가능한 속성을 가지고 있습니다. 그리고 순차적으로 실행되기 때문에 하나의 처리 시간이 긴 만큼 다른 인터럽트의 응답이 지연될 수 있습니다. 이러한 불가능한 작업을 완료하기 위해 다양한 프로세스 간에 전환하여 다양한 작업을 완료할 수 있는 작업 대기열이 등장했습니다. 　 연기된 작업에 절전 모드가 필요한 경우 작업 대기열을 선택하세요. 절전 모드가 필요하지 않은 경우 소프트 인터럽트 또는 tasklet을 선택하세요. 작업 대기열은 프로세스 컨텍스트에서 실행될 수 있으며 작업을 커널 스레드에 위임할 수 있습니다. 간단히 말해서 작업 대기열은 인터럽트 데몬 스레드로 사용되는 커널 스레드 그룹입니다. 여러 인터럽트를 하나의 스레드에 배치하거나 각 인터럽트에 스레드를 할당할 수 있습니다. 커널 스레드를 사용하여 구현되는 작업자 스레드를 나타내기 위해 workqueue_struct 구조를 사용합니다. 작업자 스레드는 연기된 작업을 어떻게 실행합니까—— work_struct 구조로 구성된 연결 목록이 있으며, 이 work_struct는 작업이 완료되면 해당 work_struct를 설명합니다. 연결된 목록에서 개체가 제거됩니다. 연결된 목록에 개체가 더 이상 없으면 작업자 스레드는 계속 절전 모드로 전환됩니다. 작업 대기열은 스레드이므로 스레드에서 사용할 수 있는 모든 메서드를 사용할 수 있습니다. Linux에서 소프트 인터럽트와 작업 대기열의 역할은 무엇입니까? Linux에서 소프트 인터럽트와 작업 대기열의 역할은 인터럽트 처리를 구현하는 것입니다. 상부 및 하부 메커니즘의 절반 구현 메커니즘. 　　1.소프트 인터럽트는 일반적으로 "deferrable function " 의 총칭입니다. 인터럽트 컨텍스트에 있으므로 자체적으로 인터럽트할 수 없습니다. . 하드웨어 인터럽트(상단)에 의해 중단될 수 있으며 여러 CPU에서 동시에 실행될 수 있습니다. 따라서 소프트 인터럽트는 재진입 기능으로 설계되어야 하므로 데이터 구조를 보호하기 위해 스핀 잠금도 필요합니다. 　　2.작업 대기열의 기능은 프로세스 컨텍스트에 있으며 잠자기 상태이거나 차단될 수 있으며 다른 프로세스 간에 전환하여 다른 작업을 완료할 수 있습니다. 연기 가능한 함수나 작업 대기열 모두 사용자의 프로세스 공간에 액세스할 수 없습니다. 지연 가능한 함수가 실행될 때 작업 대기열의 기능은 커널 프로세스에 의해 실행될 수 없습니다. 사용자 공간 주소. 관련 추천: " Linux 비디오 튜토리얼 "

위 내용은 Linux Softirq 및 작업 대기열의 역할은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!