2005/12/12, Arjan van de Ven <arjan@xxxxxxxxxxxxx>:
On Mon, 2005-12-12 at 14:18 +0800, Hsieh Steve wrote:
> In linux 2.4 the kernel is non-preemptive
> That is, at any time, a process running in kernel mode can not be
> preempted by another user process, right?
>
> Consider a user process issue a syscall, trap into kernel and when it
> stay in kernel mode, the timer interrupt comes and
> the process find the its own time quantum is used
> up(task_struct->counter <=0)
> it should be schduled out after timer interrupt complete, right?
>
nope; only when the kernel returns to userspace or schedules internally
will the time quantum event have a consequence.
This may sound bad but you have to remember that in general the kernel
has very short execution paths, so this extra "delay" isn't usually as
horrific as it sounds.
Hi,
thank for your reply and I still get some place I dont understand
you mean the user process which is running in kernel mode will not be preempted
even if the time quantum is used up .That is , the preemption is deferred to the time when it
returnto user mode, right?
If so, consider a kernel thread contend for a spinlock which is hold by other process,
the kernel thread has NO chance to return to the user mode(it always in kernel mode)
will it occupy the CPU forever??
if so, is it implied that the spinlock in never be used in a kernel thread??
