From: Hubertus F. <fr...@us...> - 2001-02-12 16:52:19
|
In the priority list scheduler posted on the website, I moved those tasks into a separate bucket, which is never searched during regular scheduling. Easy to integrate into the MQ scheduler as well as you said using a separate "runqueue" list. Hubertus Franke Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) , OS-PIC (Chair) email: fr...@us... (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003 In reply to: -------------- Jun Nakajima <ju...@sc...>@sco.com on 02/12/2001 10:54:32 AM Sent by: nak...@sc... To: Rik van Riel <ri...@co...> cc: John Hawkes <ha...@en...>, Hubertus Franke/Watson/IBM@IBMUS, Mike Kravetz <mkr...@se...>, lse...@li... Subject: Re: [Lse-tech] cpus_allowed in multi-queue scheduler Rik van Riel wrote: > > > Also, recalculating the priority of *every* task in the system > at recalculation time has the possibility of blowing away a too > large portion of the cache if you're running with huge amounts > of processes (and some nice ping-pong effects if you have multiple > CPUs recalculating at once, as can happen when you have a bunch of > nice +19 processes). In addition, the non-realtime tasks with the time quantum expired are still on the run queue, and goodness() against them always returns 0. The scheduler keeps on checking such expired tasks as well, wasting CPU cycles and cache lines, until the next recalculation time. If the number of the tasks on the run queue is N and no rescheuduling is requested except when the time quantum expires, the scheduler basically checks such tasks N times per task. Those extra N-1 checks can be avoided. One solution to this is to move such expired tasks to another (run) queue when their time quantum expires, and concatenate that queue and the run queue (that may have realtime tasks) at recalculation time. The same thing can be done with the MQ scheduler, although the per-CPU run queue does not have realtime tasks. > > regards, > > Rik -- Jun U Nakajima Core OS Development SCO/Murray Hill, NJ Email: ju...@sc..., Phone: 908-790-2352 Fax: 908-790-2426 |
From: george a. <ge...@mv...> - 2001-02-13 02:13:12
|
Hubertus Franke wrote: > > In the priority list scheduler posted on the website, I moved those tasks > into a separate bucket, which is never searched during regular scheduling. > Easy to integrate into the MQ scheduler as well as you said using a > separate > "runqueue" list. Next you would want to recaculate the counter for each task as it is moved. Then you never have to take a "time out" to do the whole list. When the current list is empty, just switch to the "separate" list and keep rocking. George > > Hubertus Franke > Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) > , OS-PIC (Chair) > email: fr...@us... > (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003 > > In reply to: > -------------- > > Jun Nakajima <ju...@sc...>@sco.com on 02/12/2001 10:54:32 AM > > Sent by: nak...@sc... > > To: Rik van Riel <ri...@co...> > cc: John Hawkes <ha...@en...>, Hubertus Franke/Watson/IBM@IBMUS, > Mike Kravetz <mkr...@se...>, lse...@li... > Subject: Re: [Lse-tech] cpus_allowed in multi-queue scheduler > > Rik van Riel wrote: > > > > > > Also, recalculating the priority of *every* task in the system > > at recalculation time has the possibility of blowing away a too > > large portion of the cache if you're running with huge amounts > > of processes (and some nice ping-pong effects if you have multiple > > CPUs recalculating at once, as can happen when you have a bunch of > > nice +19 processes). > > In addition, the non-realtime tasks with the time quantum expired are > still on the run queue, and goodness() against them always returns 0. > > The scheduler keeps on checking such expired tasks as well, wasting CPU > cycles and cache lines, until the next recalculation time. If the number > of the tasks on the run queue is N and no rescheuduling is requested > except when the time quantum expires, the scheduler basically checks > such tasks N times per task. Those extra N-1 checks can be avoided. > > One solution to this is to move such expired tasks to another (run) > queue when their time quantum expires, and concatenate that queue and > the run queue (that may have realtime tasks) at recalculation time. > > The same thing can be done with the MQ scheduler, although the per-CPU > run queue does not have realtime tasks. > > > > > regards, > > > > Rik > > -- > Jun U Nakajima > Core OS Development > SCO/Murray Hill, NJ > Email: ju...@sc..., Phone: 908-790-2352 Fax: 908-790-2426 > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > http://lists.sourceforge.net/lists/listinfo/lse-tech |
From: george a. <ge...@mv...> - 2001-02-13 02:16:53
|
Lets try this under a realistic subject :-) Hubertus Franke wrote: > > In the priority list scheduler posted on the website, I moved those tasks > into a separate bucket, which is never searched during regular scheduling. > Easy to integrate into the MQ scheduler as well as you said using a > separate > "runqueue" list. > Next you would want to recalculate the counter for each task as it is moved. Then you never have to take a "time out" to do the whole list. When the current list is empty, just switch to the "separate" list and keep rocking. George > Hubertus Franke > Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) > , OS-PIC (Chair) > email: fr...@us... > (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003 > > In reply to: > -------------- > > Jun Nakajima <ju...@sc...>@sco.com on 02/12/2001 10:54:32 AM > > Sent by: nak...@sc... > > To: Rik van Riel <ri...@co...> > cc: John Hawkes <ha...@en...>, Hubertus Franke/Watson/IBM@IBMUS, > Mike Kravetz <mkr...@se...>, lse...@li... > Subject: Re: [Lse-tech] cpus_allowed in multi-queue scheduler > > Rik van Riel wrote: > > > > > > Also, recalculating the priority of *every* task in the system > > at recalculation time has the possibility of blowing away a too > > large portion of the cache if you're running with huge amounts > > of processes (and some nice ping-pong effects if you have multiple > > CPUs recalculating at once, as can happen when you have a bunch of > > nice +19 processes). > > In addition, the non-realtime tasks with the time quantum expired are > still on the run queue, and goodness() against them always returns 0. > > The scheduler keeps on checking such expired tasks as well, wasting CPU > cycles and cache lines, until the next recalculation time. If the number > of the tasks on the run queue is N and no rescheuduling is requested > except when the time quantum expires, the scheduler basically checks > such tasks N times per task. Those extra N-1 checks can be avoided. > > One solution to this is to move such expired tasks to another (run) > queue when their time quantum expires, and concatenate that queue and > the run queue (that may have realtime tasks) at recalculation time. > > The same thing can be done with the MQ scheduler, although the per-CPU > run queue does not have realtime tasks. > > > > > regards, > > > > Rik > > -- > Jun U Nakajima > Core OS Development > SCO/Murray Hill, NJ > Email: ju...@sc..., Phone: 908-790-2352 Fax: 908-790-2426 > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > http://lists.sourceforge.net/lists/listinfo/lse-tech |