Messages in this thread | | | Date | Sun, 6 Jan 2002 19:23:57 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [patch] mqo1 changes ... |
| |
On Sat, 5 Jan 2002, Davide Libenzi wrote:
> Ingo, there a fix in ksyms.c ( missing ; ).
thanks, applied, it's in -C1.
> There's a checkpointing code for rt tasks.
thanks, we can certainly do something like this, i've added a variation of this to -C1. One thing your patch misses: we need to update the event counter when we remove RT tasks as well.
> Ingo, are you sure we need to lock the whole lock set to do rt queue > pickups ? > RT lock ( first ) + prev-task lock ( next ) should be sufficent. > The lock rule will become 1) RT 2) cpu
i had something like this in previous scheduler versions and it was deadlock land. But i agree that we can do better and i've already started relaxing the draconian RT locking rules again in my tree. (that's not in -C1 yet.) But it's much more complex than what you describe, because the ->policy value and ->cpu can change as well, so locking in this manner has to be done very carefully.
> The estimator has been removed and the prio/timeslice logic has been used. > Each time there's a swap on arrays the rq counter is increased.
not applied. I had this in the very first version of the O(1) scheduler, it was called expire_count:
+ unsigned long nr_running, nr_switches, expire_count;
i replaced it with the current estimator, which works much better in a number of trickier workloads.
> Each time a task is injected inside the run queue its priority is fastly > updated == bonus for sleeping tasks. > Each time a task exaust its time slice its priority is decreased, penalty > for cpu hungry tasks.
i found this to be a too simple approach that doesnt work for some workloads. The history-based load estimator i wrote is sound from a theoretical point of view, it calculates an integral of the load value and thus represents the load history of the task accurately.
this estimator is well-tested under a number of workloads which do break under simpler schemes like the switch-counter based estimator. (the 4-entry history estimator clearly beats even some estimators that are more accurate than the switch-count based estimator - like the run/sleep timestamping estimator or the single-entry history estimator.)
the way i developed/tested the estimator was to put the system under various extreme loads and i traced interactive processes. If they were not working smoothly (ie. they were starved of the runqueue despite their interactive nature) then i changed the estimator.
so if you'd like to replace it then please do not do it casually, trace the difference under a number of important workloads - i have done so.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |