On Mon, May 14, 2007 at 01:10:51PM +0200, Ingo Molnar wrote: > but let me give you some more CFS design background:
Thanks for this excellent explanation. Things are much clearer now to me. I just want to clarify one thing below: > > 2. Preemption granularity - sysctl_sched_granularity [snip] > This granularity value does not depend on the number of tasks running. Hmm ..so does sysctl_sched_granularity represents granularity in real/wall-clock time scale then? AFAICS that doesnt seem to be the case. __check_preempt_curr_fair() compares for the distance between the two task's (current and next-to-be-run task) fair_key values for deciding preemption point. Let's say that to begin with, at real time t0, both current task Tc and next task Tn's fair_key values are same, at value K. Tc will keep running until its fair_key value reaches atleast K + 2000000. The *real/wall-clock* time taken for Tc's fair_key value to reach K + 2000000 - is surely dependent on N, the number of tasks on the queue (more the load, more slowly the fair clock advances)? This is what I meant by my earlier remark: "If there a million cpu hungry tasks, then the (real/wall-clock) time taken to switch between two tasks is more compared to the case where just two cpu hungry tasks are running". -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
