Date: Wed, 24 Nov 1999 10:35:39 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Julian Elischer <julian@whistle.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911241835.KAA19645@apollo.backplane.com> References: <Pine.BSF.4.10.9911232348550.11412-100000@current1.whistle.com> <383BD145.57BA3C7C@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
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?199911241835.KAA19645>