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

On Tue, Jun 24, 2008 at 23:34, Jorge G. Mare <kokitomare@xxxxxxxxx> wrote:
> Welcome back André!
> Just curious: is this part of the still to be finished "Create a thread
> scheduler with CPU affinity" GSoC 2007 project, or is this something new?

Hi, Koki!

It's still part of the GSoC 2007 project. I was swamped by college and
since I saw no hope of having any free time left to work on it, tried
to reorganise things so that the project became one of my final
college assignments. ;)


On Tue, Jun 24, 2008 at 20:39, François Revol <revol@xxxxxxx> wrote:
> Also, We use real-time priority for threads that need it (like mouse
> mover, ...), and there is a suggest_thread_priority function that takes
> into account what the thread is to do.

Are we that confident on suggest_thread_priority? AFAICT it
guesstimates a priority level based on a dozen classes of CPU usage
(13 in the Zeta version). And consider that those were defined in the
nineties; how fitting are B_LIVE_VIDEO_MANIPULATION, B_VIDEO_PLAYBACK
B_VIDEO_RECORDING, B_LIVE_AUDIO_MANIPULATION, B_AUDIO_PLAYBACK,
B_LIVE_3D_RENDERING etc now that video cards are effectively
programmable stream processors with key audio, video and physics
processing routines built right in the hardware?

Not trying to sound self-congratulating here, I'm trying to push the
envelope regarding the subject of threading. suggest_thread_priority
can't possibly cover the whole gamut of processing possibilities, let
alone consider how hardware evolved to offload a lot of duties from
the CPU. It was conceived back when symmetric multiprocessing was the
buzzword and playing Quake on a Voodoo 3 was jaw-dropping impressive;
now we're taking a page from the 80's and integrating dedicated
streaming processors on commodity hardware.

So how about we let go of this smart trick that served us pretty well
in days when the BeOS scheduler was static and never cared about
boosting/demoting threads, and lend the scheduler (or not really,
since I'm proposing to slightly tweak the locking primitives) some
intelligence and implement something that builds upon roughly 20 years
of scheduling research?

> Only the process using the kernel knows what it wants from it, the
> kernel shouldn't need to guess what can be told to it by other means.

Sometimes not even the process using the kernel knows what it wants
from it, cf. ported software. Sometimes not even the programmer itself
knows that it wants from a thread.  Sometimes the programmer is forced
to spawn a new thread to perform a task that doesn't quite fit the
general declared duty of a thread, which would otherwise sabotage the
very purpose of suggest_thread_priority. And remember how the biggest
difficulty in writing software for BeOS was getting "that threads
thing" right. I hope someday everyone will know how to write top notch
threaded software, but until then we shouldn't assume everyone is a
gifted parallel programming coder.

On Wed, Jun 25, 2008 at 00:37, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> It surprises me every time anew, how you manage to write a short novel on a
> relatively compact topic. :-)

LOL!

In fact it's quite easy when you have to write an essay that's over 50
pages on the subject of scheduling ;)

> Well, it adds overhead.

If my proposal is as effective as I believe it is, I'm willing to live
with the overhead of a single integer, a conditional test, a sum and
an assignment. ;)

> The main question is whether this kind of
> optimization is necessary at all. As François already mentioned threads
> that need very low latencies (and don't do much work) just get a high
> priority. Analogously worker threads should be given priorities lower than
> B_NORMAL_PRIORITY. IMHO when these simple rules are respected a relatively
> fair scheduler would automatically schedule threads in such a way that the
> interactive user experience is just fine.

Well, the key here is exactly what you just brought: would everybody
play by the rules all the time? Would ported software play by our
rules? Would software by newcoming developers play by our rules? Would
software that depend mostly on interpreted languages (Java, Python,
Lua, Ruby, you name it) play by our rules? I don't quite think so.

If going my route buys us *nothing* but a better experience when
running ported software where upstream won't accept patches with
Haiku-specific tweaks to their threading code I'd consider my mission
thoroughly accomplished: Java, Firefox, Webkit, OpenOffice, AbiWord,
GNU tools, countless games; those are all ported software after all.
Until we manage to convince them to tune their software to Haiku
there's no reason we should settle for having responsiveness issues
when running said software, and if a smart scheduler makes this point
kind of mute it would actually encourage people to port their software
over to Haiku. And make the job of writing native software even
easier. The best code is code that doesn't have to be written at all,
isn't it? How about not having to write a call to
suggest_thread_priority? ;)

> Interactions with Haiku's GUI involve quite a few threads that mostly
> communicate via messaging. I wouldn't be much surprised if I'd be told that
> most of those threads most of the time don't use their full quantum before
> they have to wait for a lock or the next message. To me keeping scheduling
> paths short seems to be the best best way to ensure low latencies.

And I'm trying to do just that: write a fair scheduler and eliminate
heuristics from it. Even simple ones like randomly skipping threads. I
want it to be smart by design, not by heuristics.

> Not sure what you expect. Messaging uses ports, ports use semaphores. If
> you wait for a message on an empty message port or want to write a message
> to a full one, you effectively wait on a semaphore.
> I don't see why this shouldn't be possible.

Perfect.

> To be honest, I'm very sceptical whether this kind of optimization is
> really useful.

Did I manage to convince you? ;)

And it's not really an optimisation, it's doing away with heuristics
that we see implemented on other OSs to achieve decent responsiveness.
Axel told me he'd like me to implement something like the heuristics
Jeff Robertson introduced in the current FreeBSD scheduler, and I'm
proposing a different approach altogether that should yield even
better results.


Cheers,
A.

Other related posts: