From: george a. <ge...@mv...> - 2001-02-13 22:12:44
|
Jun Nakajima wrote: > > I should be responsible for this. It's not Rik's statement. > > I don't understand why you end up 30 writes per task. If we simply > modify the link fields of the queue head (and the first task on the > queue) at rejuvenation time, like: > list_splice(&expired_stuff_head, &runqueue_head); > you don't need to modify the run_list field of those tasks (except the > first one). > > Since we can move such tasks in schedule() with the runqueue_lock held, > we don't need an extra lock for the new queue. > > I think, however, this is a relatively minor issue in the context of > that discussion. The main issue was that we might want to avoid the "big > bang" recalculation of the priorities. And my point was if we reduce the > readers of those fields efficiently, the impact (i.e. writes to those) > would be minimal at recalculation time. > If you do the counter update when it goes to zero and then put it in the new list you spread the "big bang" out into a bunch of wispers. Given this, would the recalculation time on a given cpu be a good time to "poach" a task from a cpu that still had a a ways to go to get to recaculation time? I.e. load level based on the number of counter ticks in the run queue. George |