Just trying to help the best I can... On Mon, Aug 4, 2008 at 2:11 AM, Sukanto Ghosh <sukanto.cse.iitb@xxxxxxxxx> wrote: > 1. What is 'fair_clock' ? > (Ingo says it is 'CPU time a runnable task would have fairly gotten, > had it been runnable during that *time* ') > > How is this calculated ? > > (my understanding: suppose there are 2 runnable tasks for 4ms and in > the next 4ms there are 4 runnable tasks, then fair_clock would be > incremented by 3ms in this 8ms period ? > > If this is correct then, what is *that time* ? is it the 8ms period ? ) hard to say. My own understanding is like this: CFS learns that there are now 2 runnable tasks, each has 4 ms time slice (let's calle the tasks A and B). Assuming none of them were blocking or doing yield(), they use 4ms fully...thus 8ms is the total duration of the 1st iteration. Then on 2nd iteration, comes 2 new runnable task. Since previously total interval is 8ms, making now to 16ms won't make the tasks run fair. Thus, I think what CFS does is creating somekind of "deadline". each tasks could still own 4 ms time slice, but will be preempted after 2ms. That way, A will run for 2ms, B, C and then D also runs for 2ms. Then they will spent the rest of their 2ms time slice for 3rd iteration. I think this is what "fair clock" means... > 2. When is this fair_clock updated ( when a task is 'scheduled in' / > 'scheduled out' ) ? Likely, after scheduled out. > 4. When is a running task preempted ? Or, how is the length of the > timeslices calculated ? well, process is preempted when it is blocking...or exhaust it's time slice...or entering what I call "scheduling point" i.e going to user space from kernel space after syscall. But in CFS context, i think it is also preempted when its "fair clock" is expired.... > 5. The entries (tasks) in the rbtree are sorted on the basis of key = > 'rq->fair_clock - p->wait_runtime'. Suppose a running task is > preempted after running for t ns, then its key would change (as > p->wait_runtime is decremented by t). So, will this task be deleted > and re-inserted into the rbtree as per its new key value ? I believe, purely a technical guess, that's the way to go. regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
