From owner-freebsd-arch Sun Nov 28 10:54:47 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 1F09014BE4 for ; Sun, 28 Nov 1999 10:54:42 -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 TAA25954 for ; Sun, 28 Nov 1999 19:54:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA58788 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 19:54:41 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CCF0E15722 for ; Sun, 28 Nov 1999 10:54:11 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt88.pcnet.net [206.105.29.162]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id NAA08837; Sun, 28 Nov 1999 13:54:09 -0500 (EST) Message-ID: <38417A7F.B23C701D@vigrid.com> Date: Sun, 28 Nov 1999 13:54:55 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Problems: > > * You have to manage dynamic allocation and deallocation of KSE's > (verses simply preassigning one per thread). > > * You have non-deterministic resource utilization for an application. > The worst case KSE useage is going to be one per thread, but the > userland may well allow thousands of threads to be allocated first > and then realize only later that it does not have the kernel > resources to block in all of them at once, leading to > non-deterministic blockages. > > * You compound the management issues within the userland scheduler > itself because not only can the userland scheduler switch between > threads, now so can the kernel when it decides it must block. > (this is an argument to have a kernel entry point to schedule a > thread no matter what). I'm starting to agree with you on this. If you take into account that the UTS needs to set up a scheduling signal/upcall whenever a thread switch occurs, then why not have one system call that both switches to a new thread and sets up the scheduling signal. > > * The userland scheduler has no concept of certain types of blockages, > such as VM faults, and cannot schedule around such things itself. > This can lead to non-deterministic operation. The UTS can treat a page fault in the same way as a blockage on I/O (unless the page fault occurs in the scheduler itself). A new thread can be chosen and run, and the UTS can be notified when the page fault is cleared. > * The userland scheduler must deal with scheduling the N cpu case > itself - this is something more suitable to the kernel because the > userland scheduler has no knowledge of other unrelated > processes/threads running in the system. This means that > if the userland scheduler is trying to switch or schedule threads > without making a system call, the whole mess becomes much more > complex when the kernel winds up having to manage the same > threads itself. I think the UTS need only concern itself with its own allocated subprocesses. It multiplexes threads onto processes, and it's the kernels job to multiplex processes onto CPUs. I think I do agree with you on having to make a system call to switch threads, but I'm not completely off the fence yet ;-) > This isn't to say that the userland scheduler cannot choose a > loosely (or hard) bound cpu for a thread, only that the kernel is > better able to actualy get the thread running deterministically > because the userland scheduler might end up 'stuck' in a VM > fault or something similar. > > I am beginning to warm to the dynamic KSE concept but I think the only > way to avoid unnecessary complexity AND to avoid potential resource > sharing problems is to impose two requirements: > > * First, that thread runnability be controlled through a system call. > Ther userland can determine when to halt and run a thread and can > even assign a cpu, but it must make a system call to actually > schedule or deschedule the thread. Do we really want to be able to bind a _thread_ to a CPU? Wouldn't it be sufficient to be able to bind a process to a CPU? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message