Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Sep 2002 23:25:12 -0700
From:      Jon Mini <mini@freebsd.org>
To:        Julian Elischer <julian@elischer.org>
Cc:        Terry Lambert <tlambert2@mindspring.com>, freebsd-arch@FreeBSD.ORG
Subject:   Re: New Linux threading model
Message-ID:  <20020921062512.GB24394@elvis.mu.org>
In-Reply-To: <Pine.BSF.4.21.0209201638250.21069-100000@InterJet.elischer.org>
References:  <3D8B8E35.EDAF4450@mindspring.com> <Pine.BSF.4.21.0209201638250.21069-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Terry,

  I would also very much like to hear your thoughts on the best
possible threading system for FreeBSD. I have read several of your
messages on the subject, and I have somewhat of an idea of the kind
of system you'd like to see us write, but a clear picture of the
overall design is lacking.
  Please, write up a description of what you'd like to see. I'll ask
questions until I think I've got it and then paraphrase the whole
thing back at you, and we can attack if from the other direction
(you can correct where I'm wrong). 

  Deal? =)

Julian Elischer [julian@elischer.org] wrote :

> Ok, Terry,
> 
> I've thought of the best way that we can use your particular talents.
> 
> How about this..
> We have a particular set of scheduling requirements:
> 1/ We want threads to have as much parallelism as possible given the
> hardware
> 2/ We want a particular process to be able to contain 'subentities'
> that can be scheduled with different policies. (we call them ksegroups)
> 3/ We want simple processes to behave exactly as now, and new processes
> to compete with traditional processes on a basis SIMILAR to how
> traditional processs compete with each other.
> 4/ Partly a corrolary to 3: A threaded process can not overwhelm a
> system's scheduler with many threads. (we have a structure 'kse' that
> may come in handy for this, but if you thnk of a better way,
> consider it..
> 5/ improve handling of large numbers of threads.
> 6/ If possible allow selection of scheduler algorythms at run time (*)
> 
> (*) I said IF POSSIBLE..
> 
> Given these restraints, can you go through the literature, 
> pick out relevent examples,
> and report back to us with scheduling schemes that may work for us.
> You are also welcome to make up your own schemes based on what you read
> or feel.
> 
> I'm not saying this is how we'll go, just that it's come time that
> someone rescanned the literature again, and we could certainly do with 
> a discussion on the topic. You may recruit as many "scheduler gurus"
> as you wish to help you.
> 
> Of particular interest to you shuld be:
> 1/ READ THE CURRENT CODE (kern_switch.c and proc.h)
> 2/ The mach and chorus schedulers if you can find info on them
> 3/ SAs
> 4/ Linucks new scheduler. (READ THE CODE)
> 5/ the Solaris scheduler re: LWPs
> 
> 
> 
> 
> 
> "Should you decide to accept this mission, the secretary will of course
> deny any knowledge of your actions. This email will self destruct in
> however long it takes you to hit the 'd' key."
> 
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message

-- 
Jonathan Mini <mini@freebsd.org>
http://www.freebsd.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020921062512.GB24394>