2

In case of blocking IO, say, driver read, we call wait_event_interruptible() with some condition. When the condition is met, read will be done. I looked into wait_event_interruptible() function, it checks for condition and calls schedule(). schedule() will look for the next runnable process and does context switch and other process will run. Does it mean that, the next instruction to be executed for the current process will be inside schedule() function when this process is woken up again?

  1. If yes, if multiple process voluntarily calls schedule, then all processes will have next instruction to be executed once after it gets woken up will be well inside schedule()?

  2. In case of ret_from_interrupt, schedule() is called. When it will return? as iret is executed after that.

Krishna
  • 23
  • 3

2 Answers2

1

I think the answer to the first question is yes as that's a fairly typical way of implementing context switching. That's how OS161 works, for example.

If the scheduler is called from an ISR, everything should be the same. The scheduler should change the context and return to the ISR and the ISR should then return using IRET. It will return to a different process/thread if the scheduler chooses to switch to a different one and therefore loads its context and saves the old one.

Community
  • 1
  • 1
Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • Thanks for the response. Here I am unable to understand how _schedule()_ can return back to interrupt context? as it is not running as any process. – Krishna Feb 27 '13 at 13:19
  • There isn't much of an interrupt context per se, it's part of the current process' thread context in which the interrupt occurs. See [`Figure 4-6. "Returning from interrupts and exceptions" in section "4.9. Returning from Interrupts and Exceptions" of "Understanding the Linux Kernel, 3rd Edition"`](http://www.makelinux.net/books/ulk3/understandlk-CHP-4-SECT-9). Read the relevant sections. – Alexey Frunze Feb 28 '13 at 20:45
0

Re point 2: The iret instruction (return from interrupt handler) is executed and that gets you into ret_from_interrupt. Then Linux passes control to the task next to run (schedule()). One of the overriding considerations when writing interrupt handlers is that while they are executing many other activities are inhibited (other, lower priority, interrupts are the prime example), so you want to get out of there as fast as possible. That is why most interrupt handlers just stash away work to be done before returning, and said work is then handled elsewhere (today in some special kernel thread).

vonbrand
  • 11,412
  • 8
  • 32
  • 52
  • Thanks for the response. From the code I see that _common_interrupt_ jumps to _ret_from_intr_ after _do_IRQ_ call. From _ret_from_intr_ we hit _resume_kernel_ and from there it calls _preempt_schedule_irq()_, only if we hit **restore_all** earlier or later **iret** will be executed. Am I missing something? – Krishna Feb 27 '13 at 08:00