Re: Circular Convolution scheduler

[Nick Piggin <piggin@cyberone.com.au>]

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