Re: Question: How to force the scheduler to run after an interrupt.

Andreas Bombe (andreas.bombe@munich.netsurf.de)
Mon, 30 Aug 1999 17:42:38 +0200


On Sun, Aug 29, 1999 at 11:47:23AM -0700, gokhan sozmen wrote:
> I am working on a device driver that generates
> an interrupt when data is available. In my interrupt
> handler I call queue_task to place a task in the
> tq_scheduler queue because I want the processing
> to take place outside the context of an interrupt
> handler.

Put it on tq_immediate and mark_bh(IMMEDIATE_BH). The tq_immediate is
run as soon as all hardware irqs are handled. It runs with interrupts
enabled, which is what you want. You are still in interrupt context
however. Don't schedule and don't expect to have a particular user
space available.

> Things that won't work:
> - Calling schedule() from the interrupt handler.

Ouch.

> - Starting a new task at system initialization
> using the task_queue mechanism that gets run once
> and waits on a wait queue loop for a wake_up from
> the interrupt handler. It appears that a task queue
> task is not allowed to sleep on a wait queue.

Bzzzzzt. You don't have a task context in the task queues provided by
the system. Something else is calling your task_queues on your behalf
and you lock this process if you simply sleep. Or even worse, sleeping
from tq_immediate or tq_scheduler; you schedule from inside the
scheduler or in interrupt context.

task_queues you define and run yourself are a different thing, but then
you know the restrictions anyway because you define them.

> One possible solution would have been to start a
> kernel thread that waits on a wait queue loop.
> I guess you don't have kernel threads in Linux
> (or do you?) so that's out.

We do have them. But they would be really overkill for your task.

This is "ps 2 3 4" for me:

PID TTY STAT TIME COMMAND
2 ? SW 0:00 (kflushd)
3 ? SW 0:00 (kupdate)
4 ? SW 0:00 (kpiod)

These are all kernel threads started at system startup. Grep the
sources for kernel_thread if you want to know more.

-- 
    Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
    http://home.pages.de/~andreas.bombe/
RSA 0x886663c9  30 EC 09 73 84 7B 55 83  C4 7A 91 D9 9D C5 4B B0
DSA 0x04880A44 72E5 7031 4414 2EB6 F6B4  4CBD 1181 7032 0488 0A44

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/