> each (runnable) task in the system, I saw that the priority influences
> the result of this weight (if the counter is not zero). I'm not sure if this
> is really necessary. If you decrease this priority (using the nice syscall)
[snip]
> So what is the reason for this influence?
I put it in about 2 months (?) ago. It is there so that
non-niced processes that don't fully utilize their
timeslice (ie: multimedia player apps) get an extra
advantage over niced stuff like large compilations and
computational stuff.
Imagine this situation:
- multimedia player, nice level 0, needing 50% CPU
- large computational thingy, nice level 10
Under the old algorithm, the player would be prempted
when it's priority came below that of the niced app.
Under the new scheme, the player has a +10 bonus, as
long as it hasn't used all of it's CPU quantum.
This means that multimedia (fixed-CPU/time) apps run
smoother then before. Maybe I should add something else
too, or change the recalculation algorithm at the end
of schedule().
It might be good to change that part from:
p->counter = (p->counter >> 1) + p->priority;
to:
p->counter = (p->counter + p->priority + 1) >> 1;
This way, the counter will be set to the average value
of the priority and the counter, so that CPU intensive
tasks will not regain their full priority, while the
fixed-CPU-percentage tasks will regain their priority
faster (relative to CPU intensive tasks).
Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page | Scouting webmaster |
| - kswapd ask-him & complain-to guy | Vries cubscout leader |
| http://www.phys.uu.nl/~riel/ | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu