Please see in line.
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi....
> 1. In your previous reply, you said "ret_from_intr() also calls
> ret_from_sys_call()" . As ret_from_sys_call() will call schedule(),
> then what is the need for ret_from_intr() to jump to resume_kernel
> and then preempt_schedule_irq() and then call schedule() ?? Am I
> confused too much :) ?
As you know, when interrupt is coming, the current execution path might
be on kernel mode or user mode. That's why ret_from_intr need to decide
where to go next. If we assume that we are currently on kernel mode
execution path (for example, kernel on behalf of a process executing
system call handler), then it will jump to resume_kernel.
So what is the reason to this code flow
(ret_from_intr->preempt_schedule_irq->schedule)? To implement kernel
mode preemption :)<Raja> So you mean that the code flows to call schedule() are different when returning to user mode and the kernel mode..?I actually understood your previous reply in a different manner. I was wondering " if ret_from_intr() will definitely call ret_from_sys_call() and ret_from_sys_call() would also call schedule(), then why all these resume_call() etc to reschedule ?"So you mean "ret_from_intr() will call ret_from_sys_call() only when it is returning to user mode" ? or will ret_from_intr() always call ret_from_sys_call() ?</Raja>
> 2. Also if ret_from_intr() calls ret_from_sys_call() which in turn
> will call schedule() if the time slice is over..., then how / why
> does a non-preemptive kernel wait till it returns to user mode to
> reschedule ? Because there is a chance of calling schedule() on the
> return from interrupt handler.., right ?
Simple, because in non preemptive kernel, kernel only check the need of
rescheduling only when the process wants to jump back to user mode or
voluntarily yield its time slot (either in kernel mode or user mode).
So this is all about "obeying OS design" and how the kernel is
developed to suit this design.
Another thing is, in preemptive kernel, more things need to be checked
to make sure it is safe to preempt kernel mode execution path. By
disabling kernel preemption, you actually "shape" the kernel into
simpler form because there is less things need to be checked (just as
you saw on resume_kernel ). The cost is, as many people already prove,
likely you will get higher latency.
>Can you pls explain the above point ? What do you mean by
> "you can continue" , "you can't continue" etc ?
Sorry, the correct wording is:
" So as you can see, if preempt_count (a flag to determine whether it
is ok to do kernel preemption, if zero, then you can continue) is
zero OR irq is not disabled, then you can't continue....a kernel
panic actually :)"
"Continue" here means, "allowed to do scheduling", while "can't
continue" is the inverse :)
The logic is, before entering preempt_schedule_irq, kernel already makes
sure that preempt_count is zero AND irq is disabled, because if it's
not, you can image....during scheduling....something might come across
and force another kernel preemption.And trust me, this won't be as
funny as "Everybody Loves Raymod", it's more like "Poltergeist: The
Beginning" ;)
regards
Mulyadi
Yahoo! Photos ? Showcase holiday pictures in hardcover
Photo Books. You design it and we?ll bind it!
