[haiku-development] Re: Scheduler algorithm improvements

  • From: Mikhail Panasyuk <otoko@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 06 Nov 2009 23:20:38 +0300

06.11.09, 17:33, "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>:

> Mikhail Panasyuk  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.

The rule I refer to:
1) The likeliness for a thread to be scheduled increases with a factor 
of two for such unit of priority.

> > 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 don't know. All I know it's not worse than current Haiku implementation. They 
both have their own specifics, in some cases BeOS performs better, in other - 
Haiku. In my tests.

> > 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.

Hosting problem. Document in UTF-8 with correct content-type meta-tag but 
server reports Windows-1251. Maybe because there is floating ad window added by 
hoster... Anyway, I've converted htmls to Windows-1251, should be ok now.

> > 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.

In current Haiku implementation 119 priority thread will wait until 120 
finished with it's task. May wait too long.

> > 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.

In real world even current Haiku implementation or old BeOS one should be good 
enough in majority of cases and they are. But I believe there is room for 
improvements.

My scheduler is definately not faster because there are more commands to 
execute, but it isn't slow either (except for pow() which should be replaced 
with something else). It's better because takes more things into account which 
I believe it should. Are they significant or not - I see diffence in artificial 
tests, will see if there is anything good about this in real world soon. And it 
is customible too, again I'll see if there will be anything good about it in 
real world soon.

Mikhail.

Other related posts: