Date: Sat, 21 Sep 2002 01:58:52 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jon Mini <mini@freebsd.org> Cc: Terry Lambert <tlambert2@mindspring.com>, freebsd-arch@FreeBSD.ORG Subject: Re: New Linux threading model Message-ID: <Pine.BSF.4.21.0209210157120.23681-100000@InterJet.elischer.org> In-Reply-To: <20020921062512.GB24394@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Sep 2002, Jon Mini wrote: > 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? =) This doen't mean that "what terry says goes" but he's being complainign about the scheduler for so long that we might as well have him start the ball rolling on discussions on the topic :-) > > 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?Pine.BSF.4.21.0209210157120.23681-100000>