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

On Monday 25 September 2006 09:49, Aubrey wrote:
Oh, sorry for my unclear description, any of the peripherals can be configured
to wake up the core from its idled state to process the interrupt on
Blackfin. I should say __if no other interrupts__ here is the timer
interrupt waking up the processor every one jiffy.

And that works if interrupts are disabled as it should?

I don't understand if interrupt occurs between need_resched() and the
idle instruction, what will become the racy object? Can you comment it
detailed? thanks.

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.

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18
    ... > interrupt waking up the processor every one jiffy. ... the idle task. ... The idle task checks need_resched, which returns false, so it ... which calls the timer softirq. ...
    (Linux-Kernel)
  • Re: cx_lowest and CPU usage
    ... rtc: all values are less than 4us ... The last result most probably means that RTC IRQ was not the interrupt ... most if its time in idle thread. ...
    (freebsd-hackers)
  • Re: bug in kernel 2.6.21-rc1-git1: conventional floppy drive cannot be mounted without hangi
    ... touches to every single interrupt. ... the idle loop when processing interrupts. ... The notifier was exported initially but then some people argued I should take ... we would like to exclude useless kernel execution from being ...
    (Linux-Kernel)
  • Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18
    ... The idle task checks need_resched, which returns false, so it ... which calls the timer softirq. ... This is the point where it goes wrong, because your user task should ... but the CPU is sleeping until the next interrupt happens. ...
    (Linux-Kernel)
  • Re: [PATCH] x86_64 add missing enter_idle() calls
    ... Supposed you are in idle, you get an interrupt and you execute __exit_idle, the ... but you call the notifier yet a second time. ... must be placed in the lowest-level idle loop. ...
    (Linux-Kernel)