Hello,
Thank you for your answers. You both bring forward that there is no process context associated with the interrupt, i.e. nothing to schedule back, when the interrupt handler
would be put to sleep.
However can't you consider the interrupt handler as running in the context of the task A, that was incidentially running when the interrupt occurred (the interrupt handler
uses the stack of task A, as Jan wrote). So wouldn't it conceptually be conceivable to put the interrupt handler to sleep by saving the current CPU state (register
contents) with task A, putting task A asleep, and resume processing of the interrupt once task A is rescheduled by the scheduler?
Of course this could be considered 'unfair' with respect to task A, in that the interrupt has no relation to task A besides the fact that they happend to be on the same CPU
at the same time. But I am interested in learning if there is any fundamental reason against sleeping in an interrupt handler.
Jan Hudec wrote:
> On Tue, Jul 01, 2003 at 06:22:29PM +0200, Martin Maletinsky wrote:
> > I know, that you are not allowed to sleep in an interrupt handler. How
> > ever I am interested to understand the reason(s) for that. Was this
> > a design decision (e.g. to simplify things) for the Linux kernel, or
> > is there a fundamental reason that makes sleeping interrupt handlers
> > simply impossible? What about the page fault handler - it (probably)
> > sleeps when it has to swap in a page, why is it possible to sleep for
> > the page fault handler and not for an interrupt handler?
>
> Sleeping is implemented using scheduler. Scheduler only schedules tasks
> (design decision to keep it simple). So you need a task context to sleep
> in. Interrupt is not tied to a process (and uses stack of whichever
> happens to be scheduled) so it can't use the context because it does not
> have to be in a sane state.
>
> -------------------------------------------------------------------------------
> Jan 'Bulb' Hudec <bulb@ucw.cz>
Robert Love wrote:
> On Tue, 2003-07-01 at 09:22, Martin Maletinsky wrote:
>
> > I know, that you are not allowed to sleep in an interrupt handler.
> > How ever I am interested to understand the reason(s) for that. Was
> > this a design decision (e.g. to simplify things) for the Linux
> > kernel, or is there a fundamental reason that makes sleeping
> > interrupt handlers simply impossible? What about the page fault
> > handler - it (probably) sleeps when it has to swap in a page,
> > why is it possible to sleep for the page fault handler and not for
> > an interrupt handler?
>
> You cannot sleep in an interrupt handler because interrupts do not have
> a backing process context, and thus there is nothing to reschedule back
> into. In other words, interrupt handlers are not associated with a task,
> so there is nothing to "put to sleep" and (more importantly) "nothing to
> wake up". They must run atomically.
>
> This is not unlike other operating systems. In most operating systems,
> interrupts are not threaded. Bottom halves often are, however.
>
> The reason the page fault handler can sleep is that it is invoked only
> by code that is running in process context. Because the kernel's own
> memory is not pagable, only user-space memory accesses can result in a
> page fault. Thus, only a few certain places (such as calls to
> copy_{to,from}_user()) can cause a page fault within the kernel. Those
> places must all be made by code that can sleep (i.e., process context,
> no locks, et cetera).
>
> Hope this helped.
>
> Robert Love
--
Supercomputing System AG email: maletinsky@scs.ch
Martin Maletinsky phone: +41 (0)1 445 16 05
Technoparkstrasse 1 fax: +41 (0)1 445 16 10
CH-8005 Zurich
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
