Messages in this thread | | | Date | Tue, 14 Oct 2003 20:28:59 +1000 | From | Nick Piggin <> | Subject | Re: Circular Convolution scheduler |
| |
Jamie Lokier wrote:
>Nick Piggin wrote: > >>I don't know anything about it, but I don't see what exactly you'd be >>trying to predict: the kernel's scheduler _dictates_ scheduling behaviour, >>obviously. Also, "best use of system resources" wrt scheduling is a big >>ask considering there isn't one ideal scheduling pattern for all but the >>most trivial loads, even on a single processor computer (fairness, latency, >>priority, thoughput, etc). Its difficult to even say one pattern is better >>than another. >> > >Hmm. Prediction is potentially useful. > >Instead of an educated ad-hoc pile of heuristics for _dictating_ >scheduling behaviour, you can systematically analyse just what is it >you're trying to achieve, and design a behaviour which achieves that >as closely as possible. >
Maybe, although as I said, I just don't know what exactly you would predict and what the goals would be.
And often you'll be left with an ad-hoc pile of heuristics driving (or being driven by) your ad-hoc analysis / prediction thingy. Analysing the end result becomes very difficult. See drivers/block/as-iosched.c :P
> >This is where good predictors come in: you feed all the possible >scheduling decisions at any point in time into the predictor, and use >the output to decide which decision gave the most desired result - >taking into account the likelihood of future behaviours. Of course >you have to optimise this calculation. > >This is classical control theory. In practice it comes up with >something like what we have already :) But the design path is >different, and if you're very thoroughly analytical about it, maybe >there's a chance of avoiding weird corner behaviours that weren't >intended. >
You still have an ad-hoc starting point because it is not clear what scheduling choices are the best.
> >The down side is that crafted heuristics, like the ones we have, tend >to run a _lot_ faster. >
That too
- 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/
| |