Re: Re: Re: Re: Understanding non-preemptive kernel

[Rajaram Suryanarayanan <rajaram_linux@xxxxxxxxx>]

Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

Hi....

> So you mean that the code flows to call schedule() are
> different when returning to user mode and the kernel mode..?

Yes. Different thing needs to be done when you return to kernel space or
user space

To get clearer picture, please see arch/i386/kernel/entry.S beginning
with the label ret_from_intr. I am not so fluent in assembly, so I also
have limitation on understanding the codes.

>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() ?

This part, I need to apologize. I drew this conclusion simply by reading
Understanding The Linux Kernel 2nd edition (which is based on 2.4.x)
without actually looking on actual code. So allow me to correct them.

First of all, the label ret_from_sys_call no longer exists. Seems like
it is now renamed syscall_exit.

Second, what I meant by "ret_from_intr calling 'ret_from_sys_call' " is,
some codes are shared between them, so it's not like function A is
call()-ing B and so on. These codes fragment are executed by "jmp"-ing
into them. For example, try to look on entry.S and you will see that
resume_userspace is "called" from both ret_from_intr and system_call.
Again, "jmp " is used here...not "call "

regards

Mulyadi


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/

Thanks Mulyadi. I understand that ultimately looking through the code will only help.

btw..I have few new questions to you. Please see below.

 

1. In Robert Love's book, he describes timeslice as "how long a task can run untill it is preempted".

I also see his subsequent description like " a process does not have to use all its timeslice at once. For example, a process with a 100 millisecond timeslice does not have to run for 100 milliseconds in one go....it can run on five different reschedules for 20 milliseconds each."

The second description seems to contradict with the first one. If timeslice is the time the process can run until it is preempted, then how can the timeslice be divided in to five reschedules  ?  How can it be rescheduled without preemption ? Does it mean the process can voluntarily give up the CPU within the timeslice and then come back later ?

 

2. Also in most of the places, he says that the time slice is dependent on the priority and that both priority and timeslice are dynamically calculated by the scheduler. But suddenly, he also says that timeslice is calculated based on static priority :)

What does this mean ? Is timeslice not dependent on dynamic priority ? No relation between time slice and the dynamic recalculation of priorities of the processes ? Because static priority will be just the default 0 or whatever set initially. So if timeslice is just dependent on static priority, then what is the use of changing priorities dynamically ?

 

Regards,

Rajaram.

 

 

 

 

 

 

 

 

 

 

---

Yahoo! Messenger- Start an email from Y! Messenger,
 
plus be alerted when new emails arrive.