Прерывания времени всегда сопровождаются вызовом планировщика?

Таймер ISR не звонит schedule() непосредственно. Это заканчивает тем, что звонило update_process_times() таким образом, учетная информация процесса планировщика актуальна.

Планировщик в конечном счете называют при возврате к пространству пользователя. Если ядро является приоритетным, это также называют при возврате от прерывания по таймеру до kernelspace.

Как пример, вообразите процесс, который выпускает syscall, который прерван сгенерированным устройством прерыванием, которое затем прервано прерыванием по таймеру:

   process A userspace → process A kernelspace → device ISR → timer ISR
                    syscall               device IRQ    timer IRQ

Когда таймер концы ISR, это возвращается к другому ISR, который затем возвращается к kernelspace, который затем возвращается к пространству пользователя. Приоритетное ядро проверяет, должно ли оно перенести процессы при каждом возврате. Неприоритетное ядро только делает ту проверку при возврате к пространству пользователя.

На земле ARM путь выполнения кода идет широко как:

• IRQ получил, в то время как в пространстве пользователя заканчивает тем, что звонил __irq_usr, в то время как IRQ получил, в то время как в SVC режим заканчивает тем, что звонил __irq_svc. IRQs не должен быть получен в то время как в других режимах процессора.
• В __irq_svc, после обработки IRQ, если ядро является приоритетным, не отключено вытеснение, и переносить необходимо, переходы ядра к svc_preempt, который звонит preempt_schedule_irq, который звонит schedule. Иначе нет перенесите, сделан.
• В конечном счете ЦП возвратится к пространству пользователя, любому от обработчика IRQ (__irq_usr → ret_to_user_from_irq), или от syscall (vector_swi → ret_fast_syscall). Там, ядро проверяет, существует ли работа, которая будет сделана, и если переносить необходимо, schedule назван.