[openbeos] Re: [Open-beos-kernel-devel] Re: GSoC ticket #1069 (thread scheduler) application
- From: "André Braga" <meianoite@xxxxxxxxx>
- To: "Open BeOS kernel development" <open-beos-kernel-devel@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Apr 2007 16:33:28 -0300
On 4/10/07, Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> 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.
Other related posts:
