Since the new 2.6.x O(1) scheduler I'm having latency problems. Probably due to excessive use of sched_yield in code in components I don't have control over. This 'problem'/behavioral change has been reported also by other applications (e.g. OpenLDAP, Gnome netmeeting, Postgress, e.google...)
I have analysed the sched_yield code in kernel/sched.c (2.6.16 SLES10) and have 3 questions/proposals: 1) Would it be beneficial to give each task one try to be enqueued on the end of the active queue (by means of a boolean flag, reset each time the time slices reach 0 and it is put in the expired list by scheduler_tick)? 2) When a task is eventually put in the expired list in sched_yield, give it back the full time slices round (as done in scheduler_tick), not with the remaining slices as is done now? 3) Put the task in the expired list at a random position, not at the end as is done now? Rationales: For 1) suppose the resource that the task wants to acquire (if any) and for which it yields, since it is not available, is kept by another task that is in the active list, behind this task. Putting the task on the expired list would induce some kind of 'tail chasing'. This would be broken by 1. For 2) When a task is put on the expired list with e.g. 1 time quantum left, next time it gets the resource and is put on the expired list at the next scheduler_tick occurence, before it has the chance to release the resource again, keeping it for a longer time than necessary. For 3) when the resource (if any) is requested by many tasks regularly, always putting the yielding task at the end of the expired list could result in 'unfairness' since the resource is handed out to the tasks as they get on the cpu. The only 'fairness' that can be applied with yield is than to insert in a random position. Any insight on these proposed changes? Thanks Steven Buytaert -- La perfection est atteinte non quand il ne reste rien ajouter, mais quand il ne reste rien à enlever. (Antoine de Saint-Exupéry) - 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/
