Ingo Molnar wrote: > the current task is recalculated at scheduler tick time and put into the > tree at its new position. At a million tasks the fair-clock will advance > little (or not at all - which at these load levels is our smallest > problem anyway) so during a scheduling tick in kernel/sched_fair.c > update_curr() we will have a 'delta_mine' and 'delta_fair' of near zero > and a 'delta_exec' of ~1 million, so curr->wait_runtime will be > decreased at 'full speed': delta_exec-delta_mine, by almost a full tick. > So preemption will occur every sched_granularity (rounded up to the next > tick) points in time, in wall-clock time.
The only problem I have with this fairness is the server workload that services requests by fork/thread creation. In such a case, this fairness is completely counter-productive, as running tasks unfairly inhibit the creation of peers. Giving fork/thread creation special priority may alleviate this problem. Thanks! -- Al - 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/