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

On 2007-04-12 at 01:01:11 [+0200], André Braga <[email protected]> wrote:
> On 4/11/07, Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > We're planing to have a slab allocator for our kernel anyway. If your
> > stuctures end up being small enough (i.e. smaller than a cache line; in 
> > case
> > of per-thread data you'd obviously have to separate them from struct 
> > thread
> > then) you can simply use a separate cache, which will result in exactly 
> > the
> > locality you're looking for.
> 
> I have to separate them already, since I can't break binary
> compatibility with struct thread.

struct thread is a private kernel structure. We can do anything we want with 
it. :-)

> This second approach is what I meant
> all along, actually.

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.

> That, and a clever algorithm to allocate "alike"
> threads together.

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

CU, Ingo

-------------------------------------------------------------------------
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