Changes between Version 42 and Version 43 of io_operations
- Timestamp:
- Jan 17, 2018, 7:22:41 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
io_operations
v42 v43 104 104 The completion of an I/O operation is signaled by the involved hardware device using an interrupt. In ALMOS-MKH, this interrupt is handled by the core running the server thread that launched the I/O operation. Therefore, the interrupt must be routed to the cluster containing the device descriptor involved in the I/O operation. 105 105 106 ALMOS-MKH makes the assumption that interrupt routing (from peripherals to cores) is done by a dedicated hardware device, called '''PIC''' (Programmable Interrupt Controller). This hardware device also helps the the kernel interrupt 107 handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed. 108 109 This PIC device handles four types of interrupts detailed below : 110 1. '''EXT_IRQ''' (External IRQ) generated by the external (shared) peripherals. 111 1. '''INT_IRQ''' (Internal IRQ) generated by the internal (replicated) peripherals. 112 1. '''TIM_IRQ''' (Timer IRQ) used for context switch by the timers (one timer per core). 113 1. '''IPI_IRQ''' (Inter Processor IRQ) forced remote scheduling (one IPI per core). 106 ALMOS-MKH makes the assumption that interrupt routing (from peripherals to cores) is done by a dedicated hardware device, called '''PIC''' (Programmable Interrupt Controller). This hardware device also helps the the kernel interrupt handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed. 114 107 115 108 This generic PIC device is supposed to be implemented as a ''distributed'' hardware infrastructure containing two types of hardware components: … … 117 110 * The LAPIC components (one component per cluster) interfaces the PIC infrastructure to the local cores in a given cluster. 118 111 119 === 1) EXT_IRQ === 112 The PIC device handles four types of interrupts detailed below : 113 114 ''' 1) EXT_IRQ (External IRQ)''' 115 116 These interrupts are generated by the external (shared) peripherals. 120 117 121 118 Each external IRQ is identified by an '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this index is defined - for each external device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the '''iopic_input''' structure, that is a global variable replicated in all clusters, allocated in the ''kernel_init.c'' file. … … 124 121 using the ''dev_pic_bind_irq()'' function. This function statically links the EXT_IRQ identified by its irq_id to the core running the server thread associated to the external device channel that is the source of the IRQ. As the external devices server threads are distributed on all cores in all clusters, the corresponding IRQ is routed to the relevant core. 125 122 126 === 2) INT_IRQ === 123 '''2) INT_IRQ (Internal IRQ)''' 127 124 128 Each internal IRQ is identified by an '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this index is defined - for each internal device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the local '''lapic_input''' structure, that is a global variable defined in each cluster. 125 These interrupts are generated by the internal (replicated) peripherals. 126 127 Each internal IRQ is identified by a cluster index and a local '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this index is defined - for each internal device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the local '''lapic_input''' structure, that is a global variable defined in each cluster. 129 128 130 129 The interrupt routing is local : For an internal peripheral, the server thread is always placed on a local core. The INT_IRQ, identified by its irq_id, is statically linked to the local core running the server thread by the ''dev_pic_bind_irq()'' function. 131 130 132 === 3) TIM_IRQ === 131 '''3) TIM_IRQ (Timer IRQ)''' 133 132 134 The timers generating the interrupts used for context switchare supposed to be implemented in the local LAPIC component. There is one timer, and one timer IRQ per local core, identified by an '''irq_id''' index, used as an identifier by the kernel.133 These interrupts are generated, in each cluster, by timers generating the interrupts used for context switch. They are supposed to be implemented in the local LAPIC component. There is one timer, and one timer IRQ per local core, identified by an '''irq_id''' index, used as an identifier by the kernel. 135 134 136 135 The TIM_IRQ identified by its '''irq_id''' is statically linked to the local core that has the same local index value. 137 136 138 === 4) IPI IRQ === 137 '''4) IPI_IRQ (Inter Processor IRQ)''' 139 138 140 To reduce various synchronisation mechanisms, ALMOS-MKH uses IPIs (Inter Processor Interrupt) : Any kernel instance, running on any corein any cluster can send an IPI to any other core in the architecture, using a remote write access to the relevant register in the PIC infrastructure. An IPI is handled as a special interrupt by the target core, and simply forces a scheduling on the target core. 139 These inter-processor interrupts are used by the kernel to force the scheduling on a given core in given cluster. 140 141 To reduce the latency associated to synchronisation mechanisms, ALMOS-MKH uses IPIs (Inter Processor Interrupt) : Any kernel instance, running on any corein any cluster can send an IPI to any other core in the architecture, using a remote write access to the relevant register in the LAPIC component. An IPI simply forces a scheduling on the target core. 141 142 142 143 == H) Text Terminals ==