Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18

From: Aubrey
Date: Mon Sep 25 2006 - 11:42:34 EST

On 9/25/06, Arnd Bergmann <arnd@xxxxxxxx> wrote:
It's the same problem as why sleep_on() is wrong and wait_event() is
right, you can find lots of documentation about that.

Think about a process calling nanosleep() to wait for a timeout.
It eventually ends up going to sleep and the kernel schedules
the idle task.

The idle task checks need_resched(), which returns false, so it
will call the idle instruction. Before it gets there, the timer
tick happens, which calls the timer softirq. That softirq notices
that the user process should continue running and calls wake_up(),
which makes the condition for need_resched() true.

Since we're handling that softirq that interrupted the idle task,
that task continues what it was last doing and calls the idle instruction.
This is the point where it goes wrong, because your user task should
run, but the CPU is sleeping until the next interrupt happens.

Note that you should in the future disable timer ticks during the
idle function (CONFIG_NO_IDLE_HZ or similar) to save more power, but
in that case the CPU may be in idle indefinitely after missing the
one interrupt that should have woken it up.

I digged into the code and got something different.
Between need_resched() and IDLE instruction, a timer interrupt occurs.
Yes, softirq may not schedule out to run the user task, but the
interrupt handler will.
You can find in our patch, I believe the same behavior is on the ARM/M68K.

1) Timer interrupt will call do_irq(), then return_from_int().

2) return_from_int() will check if there is interrupt pending or
signal pending, if so, it will call schedule_and_signal_from_int().

3) schedule_and_signal_from_int() will jump to resume_userspace()

4) resume_userspace() will call _schedule to run the user task.

So, here is no interrupt latency. The user task will run even between
need_resched() and IDLE instruction.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at