[haiku-development] Re: The new locking primitives and boosting -- I need some guidance here :)

On Wed, Jun 25, 2008 at 04:53, Stephan Assmus <superstippi@xxxxxx> wrote:
> I agree with Ingo. Linux just has "nice levels" AFAIK, and I don't know how
> often or fine grained they are used.

Actually the last time I checked Linux had 140 priority levels,
including RT, and processes usually receive a default priority level
which can only be decreased unless you're root. This is one of the
reasons they resort to detecting X11-ish behaviour on the kernel,
since normally threads spawned by user processes can't inform the
scheduler that they're more urgent than the myriad other threads that
have this default priority. nice(3) is seldom used AFAICT.

And since we touched this topic, the priority levels on Haiku will
probably need to be tweaked in order to implement multiuser support...

> Thread priorities are fairly well
> understood and deployed in BeOS land. I've only ever come across one
> project where there was a misunderstanding and a 3D renderer was given a
> high priority.

I'm not disputing this at all. What I am saying, instead, is that
sometimes the same thread might behave in a way, and in the next
moment behave completely differently, and any given priority level
might not capture this subtlety.

> What I mean to say is this: The current scheduler needs more work, and I
> would try first to make thread priorities work well with regards to wakeup
> "variation". If this still does not yield nice results, we can think about
> other options. Though since BeOS could do with "just" the thread
> priorities, I would say it should be enough.

Fortunately the latest design I did (the one described in the blog
posts has a flaw when threads enter and leave the scheduler which I
didn't manage to solve, so I redesigned it yet once more) behaves
quite nicely in this regard: a thread that's constantly ready will
always run with a period equal to
thread_priority/(sum_of_all_ready_threads_priorities * timeshare).
IOW, it's a pretty fair scheduler.

> As for whether or not this is desirable for R1 - I certainly think it is a
> must have. I don't know the involved code very much, but it looks like the
> scheduler should be a rather contained piece of code, so it's not like we
> are talking about changing lots of code with unforseen results. So please,
> by all means, work on it and experiment! :-)

I'm not really worried with the scheduler code per se anymore, as it's
mostly done now. You'll be hearing from me Real Soon Now(tm) ;) It's
the boosting code that I'm eyeing ATM, and load balancing code is next
(and is a subject for another short novel of a message :D), but I
agree that Haiku would probably benefit a lot from the new scheduler
without any further tweaking re priority boosting etc.


Cheers,
A.

Other related posts: