From owner-freebsd-arch Wed Nov 24 10:36: 2 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 AE08915302 for ; Wed, 24 Nov 1999 10:35:52 -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 TAA08417 for ; Wed, 24 Nov 1999 19:35:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA34919 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 19:35:50 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 87980152E8 for ; Wed, 24 Nov 1999 10:35:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA19645; Wed, 24 Nov 1999 10:35:39 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 10:35:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911241835.KAA19645@apollo.backplane.com> To: "Daniel C. Sobral" Cc: Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <383BD145.57BA3C7C@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. 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. 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). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message