From owner-freebsd-arch Wed Nov 24 11:56: 6 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 00CD71519F for ; Wed, 24 Nov 1999 11:56:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09163 for ; Wed, 24 Nov 1999 20:55:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35519 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:55:55 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0149D1519F for ; Wed, 24 Nov 1999 11:55:49 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id LAA47845; Wed, 24 Nov 1999 11:55:14 -0800 (PST) Date: Wed, 24 Nov 1999 11:55:14 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: "Daniel C. Sobral" , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911241835.KAA19645@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Nov 1999, Matthew Dillon wrote: > > :Julian, Dan, remember that reducing the overhead of task switching > :(thread switching) is of vital importance. In that light, the least > :context that has to be save/restored when a KSE blocks, the better. > : > :-- > :Daniel C. Sobral (8-DCS) > :dcs@newsguy.com > :dcs@freebsd.org > > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. This is 'linux threads', and it's what we already have, using rfork() however it's very heavyweight when compared with pure userland threads. you need something in-between, to get the advantages of both kernel support (blockable syscalls and page-faults) and the ability to schedule 1000 tiny threads effficiently (which is the model that some threaded packages use). > > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. We basically already havee that, but you need to have the ability to involve teh User Thread Scheduler in process restarts etc. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). well I agree with you to a point..And we are not planning on separate scheduling queues for threads and normal processes. Basically threads are assigned to a parent process, which is treated pretty much as it is now in a lot of ways. > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message