When a timer interrupt occurred the ISR is called to service the interrupt.

Is it okay to assume that every timer interrupt ends with a call to the scheduler on which process should continue running next?

Can that be generalized and say that every interrupt must end in a scheduler call?

  • That doesn't seem to be the case. For x86 with no preempt, apparently schedule() is called when returning to userspace (and wherever a system call blocks, also on the idle task). With preempt enabled, it's apparently also called when returning from any interrupt, and also in a few other places, e.g. on mutex_unlock() slow path, on certain conditions while receiving network packets, ...
    – ninjalj
    Jul 26, 2013 at 12:36

1 Answer 1


The timer ISR doesn't call schedule() directly. It ends up calling update_process_times() so the scheduler process accounting information is up to date.

The scheduler is eventually called when returning to userspace. If the kernel is preemptive, it is also called when returning from the timer interrupt to kernelspace.

As an example, imagine a process A which issues a syscall which is interrupted by a device-generated interrupt, that is then interrupted by a timer interrupt:

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

When the timer ISR ends, it returns to another ISR, that then returns to kernelspace, which then returns to userspace. A preemptive kernel checks if it needs to reschedule processes at every return. A non-preemptive kernel only does that check when returning to userspace.

In ARM land, the codepath goes broadly like:

  • An IRQ received while in userspace ends up calling __irq_usr, while an IRQ received while in SVC mode ends up calling __irq_svc. IRQs should not be received while in other processor modes.
  • In __irq_svc, after handling the IRQ, if the kernel is preemptive, preemption is not disabled, and a reschedule is needed, the kernel jumps to svc_preempt, which calls preempt_schedule_irq, which calls schedule. Otherwise, no reschedule is done.
  • Eventually, the CPU will return to userspace, either from an IRQ handler (__irq_usrret_to_user_from_irq), or from a syscall (vector_swiret_fast_syscall). There, the kernel checks whether there is work to be done, and if a reschedule is needed, schedule is called.
  • Thank you so much, the best answer I've found so far about the calling flow, very helpful.
    – Kindred
    Dec 27, 2018 at 14:19
  • May I ask you that if this flow is possible: process A userspace → timer ISR and would this lead to the call schedule()?
    – Kindred
    Dec 27, 2018 at 14:24
  • 1
    @ptr_user7813604: yes, the timer ISR updates timing information, and if it's time for a reschedule, it happens when returning to userspace.
    – ninjalj
    Dec 29, 2018 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .