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 :) > 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. > <Raja1> Can you pls explain the above point ? What do you mean by > "you can continue" , "you can't continue" etc ? </Raja1> 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 -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
