[haiku-development] Re: Scheduler algorithm improvements
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 06 Nov 2009 17:33:46 +0100
Mikhail Panasyuk <otoko@xxxxxxxxx> wrote:
> Things I've discovered with this tool convinced me that NewOS/Haiku
> scheduler
> in it's current state violates scheduling rule declared in Be Book /
> Be Newsletter
> (see volume III issue 45).
I couldn't find any scheduling related content in that issue.
> Which IMHO isn't good because at least for R1 Haiku should be as
> BeOS-compartible as possible.
Nope. What counts is the end result, not compatibility in the scheduler
- the BeOS scheduler is pretty bad, and there is no reason to duplicate
that one.
> I propose new Haiku scheduler algorithm.
>
> There is an article (in Russian, sorry) which explains why's and
> how's, written in Be Newsletter-style or at least I tried to make it
so:
> http://otoko.narod.ru/files/haiku/haiku_scheduler_part1.html
> http://otoko.narod.ru/files/haiku/haiku_scheduler_part2.html
There is obviously something wrong with the encoding set, so that Google
cannot translate any of it. Would be nice if you could fix this.
> 1) The likeliness for a thread to be scheduled increases with a factor
> of two
> for such unit of priority.
That's not a feature, that's just a property :-)
Anyway, there is little sense in testing a scheduler in an emulated
environment, as it might actually feel very different, no matter what
your tests imply.
> 2) This principle is true for both real-time and time-sharing
> threads. But
> time-sharing threads won't be scheduled while there are real-time
> threads
> ready to run.
Real time threads should be FIFO, or else they are no real time
threads.
> 3) There is concept of tunable (by user) "skip gaps" as an addition
> to the
> main rule (1).
Same for Zeta (which should be the same as Dano), and Haiku.
> Skip gap setting is individual for each category - real-time and
> time-sharing.
That doesn't make any sense for real time threads; the point of real
time threads is that they get CPU time when they need it.
> Anyway, all changes I propose are IMHO very easy to integrate and
> should be
> added to Haiku in the nearest future (pre-R1/R1) not only because
> it's easy
> but because they are needed now, improve (i think) performance and
> make
> Haiku more BeOSish. What do you think?
BeOS is a worthless aim when it comes to schedulers. But apart from
that, please try out your scheduling changes on the real thing, as that
will help you (and everyone else) to evaluate the changes you've done.
Artificial testing doesn't give you a clue about how it will feel in
the real world.
Also, what makes you think your scheduler is better of faster?
Personally, I don't have much complains of the scheduling experience of
the affine scheduler. At least I think that the latency problems Haiku
still has have a different cause.
Bye,
Axel.
Other related posts:
