Messages in this thread |  | | Date | Tue, 30 Oct 2001 09:19:05 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [PATCH][RFC] Proposal For A More Scalable Scheduler ... |
| |
On Tue, 30 Oct 2001, Hubertus Franke wrote:
> Davide, nice analysis. > I want to point out that some (not all) of the stuff is already done > in our scalable MQ scheduler (http://lse.sourceforge.net/scheduling). > > What we have: > ------------- > multiple queues, each protected by their own lock to avoid > the contention. > Automatic Loadbalancing across all queues (yes, that creates overhead) > CPU pooling as configurable mean to get from isolated queues to a fully > balanced (global scheduling decision) scheduler. > Also have some initial placement to the least loaded runqueue in the least > loaded pool > > We look at this as a configurable infrastructure.... > > What we don't have: > ------------------- > > The removal of PROC_CHANGE_PENALTY with a time decay cache affinity definition. > > > At ALS: I will be reporting on our experience with what we have > for a 8-way system and a 4x4-way NUMA system (OSDL) > wrt early placement, choice of best pool size ? > > Are you can get an early start at: > http://lse.sourceforge.net/scheduling/als2001/pmqs.ps
I see the proposed implementation as a decisive cut with the try to have processes instantly moved across CPUs and stuff like na_goodness, etc.. Inside each CPU the scheduler is _exactly_ the same as the UP one.
> Are you going to be a ALS ? Maybe we can chat about what the pros and cons > of each approach are and whether we could/should merge things together. > I am very intriged by the "CPU History Weight" that I see as a major > add-on to our stuff. What I am not so keen about is the fact > you seem to only do load-balancing at fork and idle time. > In a loaded system that can lead to load inbalances > > We do a periodic (configurable) call, which has also some drawbacks. > Another thing that needs to be thought about is the metric used > to determine <load> on a queue. For simplicity, runqueue length is > one indication, for fairness, maybe the sum of nice-value would be ok. > We experimented with both and didn't see to much of a difference, however > measuring fairness is difficult to do.
Hey, ... that's part of Episode 2 " Balancing the world", where the evil Mr. MoveSoon fight with Hysteresis for the universe domination :)
- Davide
- 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/
|  |