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


-
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/