Linux kernel preemption (kernel 2.6 of course)

Linux kernel preemption (kernel 2.6 of course)

[Oleg OREL]

I was browsing linux kernel to undetsnand how kernel preemption does
work. I was hacking around schedulee_tick and other functions called
out of timer interrupt and was unable to found any call to schedule()
or switch_to() to peempt currently running task, instead just mangling
around current and inactive runqueues.

That leads me to a thought that currently running task wont be
preempted within time-tick, instead it might happends in the next call
to preempt_schedule out of spin_lock for instance.
 



=====
Oleg OREL

TEL: +1 925 244-1127
CELL: +1 916 337-0608

Re: Linux kernel preemption (kernel 2.6 of course)

[Ingo Molnar]

On Fri, 7 Nov 2003, Oleg OREL wrote:

> I was browsing linux kernel to undetsnand how kernel preemption does
> work. I was hacking around schedulee_tick and other functions called out
> of timer interrupt and was unable to found any call to schedule() or
> switch_to() to peempt currently running task, instead just mangling
> around current and inactive runqueues.

the timer interrupt indeed cannot reschedule because interrupt contexts
must never schedule. But the timer interrupt does have the ability to
reschedule the currently running task, via setting the 'need resched'
flag:

                set_tsk_need_resched(p);

this flag then gets detected by the entry.S 'return from interrupt' code
[right when the timer irq returns] which then calls schedule().

	ingo

Re: Linux kernel preemption (kernel 2.6 of course)

[Robert Love]

On Fri, 2003-11-07 at 20:27, Oleg OREL wrote:
> I was browsing linux kernel to undetsnand how kernel preemption does
> work. I was hacking around schedulee_tick and other functions called
> out of timer interrupt and was unable to found any call to schedule()
> or switch_to() to peempt currently running task, instead just mangling
> around current and inactive runqueues.

Linux rarely forces a reschedule, because interrupt handlers cannot
block.  So we have the need_resched variable (in 2.6, a flag in
thread_info) to note if a reschedule is pending.

The scheduler is then invoked asap.

> That leads me to a thought that currently running task wont be
> preempted within time-tick, instead it might happends in the next call
> to preempt_schedule out of spin_lock for instance.

Yes, this is true.  With kernel preemption enabled, if a task is
executing in the kernel, and an interrupt occurs that marks
need_resched, the reschedule will take place immediately on return from
interrupt UNLESS a lock is held.  In which case the reschedule will
occur when the lock is released (specifically, when preempt_count hits
zero).

Without kernel preemption, the reschedule will not take place until the
executing task in the kernel blocks and a return to user-space occurs.

	Robert Love