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

On 4/11/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> struct thread is a private kernel structure. We can do anything we want with
> it. :-)

Ah, ok. I confused it with struct thread_info.
http://www.beunited.org/bebook/The%20Kernel%20Kit/Threads.html

> Let me clarify: "cache" would be a slab allocator cache, i.e. completely
> opaque to you. Your only interface with it (besides general cache
> un-/initialization) would be the functions to allocate and free a structure.
> You wouldn't write any allocation or caching code.

Considering we still don't have a slab allocator in place... And
considering the fact that I still need some algorithm to allocate
"alike" threads close to each other... Anyway, this is of secondary
importance.

> Out of curiosity, what would the criterion for those "alike" threads be?
> Similar priority? Same team?

I don't know. It's always tentative, always heuristic, since those
things tend to change all the time. Some experimentation is needed to
see which approach is more effective. The intention is to
automagically fetch the information about the next thread we're going
to schedule, but since we don't know that information, it's just
tentative, an educated guess. But similar priority and same team are
on the top of that list, for sure. Especially in the real-time case.

Now, really, stop worrying about it, this is all bit brushing. It
would be a bonus in case it's doable in a timely fashion, but don't
worry. I was just blabbering around ;)


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