Re: [openbeos] Re: GSoC ticket #1069 (thread scheduler) application

On 4/10/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> Ah, no, sorry. I just seemed to have missed it there.

Shall I proceed on o-b-k-d only, or on both lists, or...?

> > P.s.: no remarks, no comments, no suggestions whatsoever?
>
> I'm not exactly knowledgeable in the scheduling area. I last heard
> something about it as a student 7 or 8 years ago, and more intriguing
> algorithms weren't covered either.

FWIW, I'm not trying to design the latest word on schedulers for
Haiku. It'd be cool to study what's the cutting edge nowadays and
borrow some ideas from recent papers and whatnot, but... not before
R2. I must keep a realistic schedule (no pun intended ;)) for GSoC,
right?

> Generally, we're focussing on desktop use, not server (max throughput), nor
> real time applications. So, I believe, we want a scheduler with low
> latencies and acceptable throughput. Performance and complexity should be
> reasonably balanced.

Got it. Don't worry about that, those goals are clear in my mind.

> IMHO, a GA approach is over the top, as is your
> specialized memory allocator idea.

GA, definitely. A memory allocator is not that over the top, IMO; it's
all about having a contiguous memory space and putting related memory
objects close together and hopefully bring them into the cache at the
same time. But that's just an optimization -- one that would
potentially save thousands of cycles, may I add --, it's not even
close to being essential.

> Regarding memory usage, I think it's not that much of an issue. While it's
> generally prudent to have an eye on kernel memory usage, a few bytes more
> in struct thread won't be a problem -- even with thousand threads (a rather
> unusual case I'd say) it's only some KB after all.

You just touched on the question I was intending to ask next... What
is the realistic number of threads expected to be present on a typical
BeOS system? I don't know how typical my system would be, so I guess
I'd better run an informal poll here...

> So, freely add what you
> need and don't do nasty tricks just to save a few bytes.

Oh, please, don't take it that way. It's just a matter of using a
couple int16 instead of a couple int32 when the former are enough,
albeit requiring a little extra math. And I'm fully aware that some
CPU architectures tend to hate anything not perfectly 32/64 bits, but
I thought I should have asked anyway. I was considering the
possibility of having millions of threads -- as there is where you can
really reap the benefits of having an O(1) scheduler, or any O(1)
algorithm for the matter --, but if you say that even a thousand ones
are pretty rare...

Anyway, when the time comes, I'll surely propose a few alternatives
that can be discussed whenever the mentor(s) believe they should.

> CU, Ingo

Cheers,
A.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV