From owner-freebsd-arch Sun Nov 28 1:21:59 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 2F07014A15 for ; Sun, 28 Nov 1999 01:21:53 -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 KAA19442 for ; Sun, 28 Nov 1999 10:21:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA56800 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 10:21:48 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1F799155EA; Sun, 28 Nov 1999 01:20:11 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from daniel.sobral (root@p17-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.146]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id SAA22043; Sun, 28 Nov 1999 18:20:05 +0900 (JST) Received: (from dcs@localhost) by daniel.sobral (8.9.1/8.9.3) id SAA00334; Sun, 28 Nov 1999 18:17:33 +0900 (JST) (envelope-from dcs) From: "Daniel C. Sobral" Message-Id: <199911280917.SAA00334@daniel.sobral> Subject: rc.conf To: jkh@freebsd.org Date: Sun, 28 Nov 1999 18:17:33 +0900 (JST) Cc: freebsd-arch@freebsd.org Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [on an afterthough, I decided to cc this to -arch -- it concerns a library that handles reading/modification of rc.conf-like files] I'm thinking about the library. Right now, I have a readconf() function that the application must use for each file (as per the libconf.h I sent you :), and the app must provide the logic for multiple files itself. Ie, if it must read /etc/defaults/rc.conf first, and then read the files in one of it's variables in turn, the app should know that itself. So I was thinking in providing a readrcconf() and readloaderconf() functions that would have this logic builtin. On the plus side, if we change the logic, we don't need to change any other application, just the library (well, and all other script-type applications that source it :( ). On the negative side, if we changed the logic, and the person made world but not updated /etc, the library would be working with the new logic and the rc files would be working with the old one, with possible adverse effects. That's one thing, and it led me to consider another thing. Right now, the logic for reading rc.conf files is inside /etc/defaults/rc.conf, with some of it on each script sourcing it to allow for no /etc/defaults/rc.conf (we should remove this allowance now in 4.0, just like phk is removing all legacy garbage, btw). I was thinking in writing a small script containing that logic. Eg: #!/bin/sh if [ x$1 == xv ]; then echo /etc/defaults/rc.conf fi . /etc/defaults/rc.conf for i in ${rc_conf_files}; do if [ -f $i ]; then if [ x$1 == xv ]; then echo $i fi . $i fi done So instead of . /etc/defaults/rc.conf, one would do . /etc/sourcercconf instead. Also, applications that need to do their own sourcing could exec /etc/sourcercconf -v, and get the list of files they need to source. Any change in the logic would be restricted to that. How's that? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org Udall's Fourth Law: Any change or reform you make is going to have consequences you don't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 5:48:43 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 E047E14F82 for ; Sun, 28 Nov 1999 05:48:37 -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 OAA22289 for ; Sun, 28 Nov 1999 14:48:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA57446 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 14:48:35 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 300AC14F82 for ; Sun, 28 Nov 1999 05:48:22 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt79.pcnet.net [206.105.29.153]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA07418; Sun, 28 Nov 1999 08:48:22 -0500 (EST) Message-ID: <384132CD.91D3C180@vigrid.com> Date: Sun, 28 Nov 1999 08:49:01 -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: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Sat, 27 Nov 1999, Daniel M. Eischen wrote: > > I think it's basically right. If you saw the diagram at different > > stages, it would be easier to see. > > look at: > http://www.freebsd.org/~julian/threads Great, thanks! > The .obj file is the tgif source for the 7 stages. > stages 6 and 7 are not wuite worked out yet.. > teh question is "Who makes teh decision to pre-empt a running thread, and > continue the unblocked thread in the kernel? (step 6) Yes, I guess this is still open for discussion. I'd really like to be able to do it the SA way, having the UTS decide when to resume threads blocked in the kernel. But recalling Nate's earlier objection to this, FreeBSD excels at being a good server platform, where I/O throughput matters. What is the typical pattern of processes blocked on I/O, especially in a loaded system? Are there many tsleep/wakeups per I/O request, or are there usually just one or two tsleep/wakeup pairs? I can see that it would be advantageous to have the kernel automatically try to complete unblocked KSEs. But it needs to track the time spent in the system for each KSE, so that its respective thread doesn't starve other threads. Do we also want to place a limit on how much of the _process_ quantum is used to complete unblocked KSEs? What if we have the UTS dole out time to be used for completing unblocked KSEs? If there are no runnable higher priority threads, the UTS can say "here's some time, try to complete as many of the unblocked KSEs that you can". The kernel can use that time all at once, piecemeal, or until the UTS says "your time is revoked, I have higher priority threads". > I have shown it in step 6 as though the kernel took it upon itself to do so, > (for example at a quantum boundary) but if teh user decided to do it then the > situation would skip straight to step 7 because the thread state would already > be in the right place. > > I'm puting these out just to get comments.. > > The shaded areas are where there has been a change. > > tell me what you think of this format. > > > > > o A thread blocks in kernel, the KSE is saved, a new KSE is allocated, > > and an upcall is made to the scheduler with a unique KSE ID provided > > to identify the now blocked thread. > > > > o Scheduler receives notification of a thread blocking, tags the > > currently running thread with the KSE ID, chooses a new thread > > to run, switches to the new thread, and makes a system call to > > schedule a signal/upcall when the new threads quantum expires. > > > > o A KSE is woken up in the kernel. > > > > o Scheduler receives notification of a thread unblocking (finishing?) > > in the kernel. > > Here's where I get into difficulty.. shoul d we notify the > UTS on unblocking, or on completion? or both? Yeah, that's a tough question to answer. Perhaps we should take a simple approach for now, and try to expand on it and optimize it later. I think the simple solution is to notify the UTS and let it decide when to resume it. Once that's working, we can look at optimizing it so that the kernel can somehow try to automatically complete unblocked KSEs. Since the UTS knows which KSE is being run/resumed, tracking of time spent completing unblocked KSEs can also be added later. My $.02, FWIW. > > > > o At the request of the scheduler, the kernel schedules a timeout for > > the new quantum and resumes the now unblocked thread. > > define " the kernel schedules a timeout for > the new quantum and resumes the now unblocked thread" When the UTS is informed that a thread is now unblocked in the kernel (to the point that it can return to userland), and now wants to resume the thread, the UTS will compute the time in which a scheduling signal/upcall should be performed. It makes a system call that both resumes the thread and schedules the signal. Under your different syscall gate, this would be a longjmp followed by a call to schedule a signal. But if we're going to make a system call anyways, why not switch to the resumed thread and schedule the signal all at once? If the point of a different syscall gate is to eliminate a system call to resume an unblocked thread, then my contention is that we still have to make a system call for a scheduling signal/upcall. Combine the resumption of the thread and the scheduling of the signal (thr_resume_with_quantum), and you don't need a different syscall gate ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 8:42:46 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 EA59614BE9 for ; Sun, 28 Nov 1999 08:42:31 -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 RAA24266 for ; Sun, 28 Nov 1999 17:42:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA58041 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 17:42:28 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F38AE14BE9 for ; Sun, 28 Nov 1999 08:42:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA44909; Sun, 28 Nov 1999 08:41:57 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 08:41:57 -0800 (PST) From: Matthew Dillon Message-Id: <199911281641.IAA44909@apollo.backplane.com> To: Arun Sharma Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> <19991127205752.A7145@sharmas.dhs.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :current BSD scheduler. : :(a) schedcpu() is called every hz ticks. This requires locking the runqueues. : On a SMP system, all other processors are completely locked out. Clearly, : someone needs to redesign the system such that priorities get recomputed : in an event driven fashion. Uresh Vahalia's book (Ch 5.5.6) talks about : this. I think we are already operating under the assumption that the current scheduler must be rewritten, or at least significantly modified. Amoung other things we have to get rid of all the extra junk that is in assembler that could easily be C (I seem to recall someone actually working towards that goal, was any of that ever committed? It seemed pretty good). Ideas have already been put forth. For example, giving the scheduler its own lock (or locks) independant of the MP lock. :(b) If you want to implement processor binding, the implementation is simpler : with per cpu runqueues. A multi-queue implementation would scale better for this situation. I wouldn't go as far as to say that it would be necessarily easier from an implementation point of view. I think of it in these terms: You have a process which may have no binding restrictions, loose binding restrictions, or hard binding restrictions. Most of the thread support is going to be classified as having loose binding restrictons or none at all (i.e. a general purpose setup). Hard binding is easiest with multiple queues for obvious reasons, but loose/no binding is easiest with a single queue. From an implementation point of view. :(c) Although not a justification by itself, I remember reading that the most : recent version of AIX uses per cpu runqueues to scale better on SMP. : :On the other hand, implementing scheduler activations and SMP scaling :simultaneously would be too much of a change. It might be a good idea :to do one thing at a time. : : -Arun I'm thinking that it would be easier to augment the single run queue we currently have first and then redo it later after the rest of the system has been made more SMP aware. In regards to performance, right now the scheduler is the least of our worries. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 9:22:20 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 DBD02150A3 for ; Sun, 28 Nov 1999 09:22:18 -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 SAA24679 for ; Sun, 28 Nov 1999 18:22:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA58227 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 18:22:17 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DA05815724 for ; Sun, 28 Nov 1999 09:22:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA45015; Sun, 28 Nov 1999 09:21:58 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 09:21:58 -0800 (PST) From: Matthew Dillon Message-Id: <199911281721.JAA45015@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <3840B1EC.4614AAF0@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> I don't know what Danthiks but this has alot more involvement or the :> kernel and boundary crossing than I was envisionning. : :I think it's basically right. If you saw the diagram at different :stages, it would be easier to see. : : o A thread blocks in kernel, the KSE is saved, a new KSE is allocated, : and an upcall is made to the scheduler with a unique KSE ID provided : to identify the now blocked thread. : : o Scheduler receives notification of a thread blocking, tags the : currently running thread with the KSE ID, chooses a new thread : to run, switches to the new thread, and makes a system call to : schedule a signal/upcall when the new threads quantum expires. : : o A KSE is woken up in the kernel. : : o Scheduler receives notification of a thread unblocking (finishing?) : in the kernel. : : o At the request of the scheduler, the kernel schedules a timeout for : the new quantum and resumes the now unblocked thread. : :> I will try make aset of diagrams that outline the state of various :> objects related to a thread at various stages.. : :How about an animated GIF or MOV? ;-) : :Dan Eischen :eischen@vigrid.com Advantages: * Kernel stack sharing by multiple threads in the non-blocking case, which can lead to better memory and cache resource utilization. * An infinite number of threads can be created as long as they do not all need a kernel stack simultaniously. * Kernel management issues are complex, but not terribly so. For example, you have a thousand threads and they all suddenly decide to block inside the kernel - the kernel needs a mechanism to disallow kernel entry (setup the thread to force a restart of the system call and then switch threads because no KSE resources are available). 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). * 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 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. 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. * Second, KSE management. The kernel has a limited number of KSE's available and cannot allow any one process (containing multiple threads) to hog them. KSE management must be dynamic on-entry. This means that when a thread makes a system call and enters the kernel, the kernel must make a determination in regards to the availability of KSE's. If insufficient KSE's are available (or the process is using too many already), the kernel must setup the thread to restart the system call, deschedule it, and switch to another thread. i.e. there is always a 'current KSE' for a running thread, but if it is the last one and the system call MIGHT block, the kernel cannot afford to allow the thread to block in the one remaining KSE and must deschedule the thread until KSEs are available to handle the system call. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 10:26:26 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 13908150DD for ; Sun, 28 Nov 1999 10:26:23 -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 TAA25638 for ; Sun, 28 Nov 1999 19:26:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA58577 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 19:26:20 +0100 (MET) Received: from c62443-a.frmt1.sfba.home.com (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 0F59D150DD for ; Sun, 28 Nov 1999 10:26:13 -0800 (PST) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.9.3/8.9.3) id KAA08579; Sun, 28 Nov 1999 10:26:12 -0800 Date: Sun, 28 Nov 1999 10:26:12 -0800 From: Arun Sharma To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991128102612.A8570@sharmas.dhs.org> References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> <19991127205752.A7145@sharmas.dhs.org> <199911281641.IAA44909@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199911281641.IAA44909@apollo.backplane.com>; from Matthew Dillon on Sun, Nov 28, 1999 at 08:41:57AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 28, 1999 at 08:41:57AM -0800, Matthew Dillon wrote: > I think we are already operating under the assumption that the current > scheduler must be rewritten, or at least significantly modified. Amoung > other things we have to get rid of all the extra junk that is in assembler > that could easily be C (I seem to recall someone actually working towards > that goal, was any of that ever committed? It seemed pretty good). Yes, that was commited. But I think it can be better. Right now, the code goes from C -> asm (context switch out) -> C (pick a new process) -> asm (switch in) -> C I think it should be lock C (pick a new process p) asm (switch from curproc to p) unlock -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message 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 From owner-freebsd-arch Sun Nov 28 14:11:30 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 ECD1B14BEE for ; Sun, 28 Nov 1999 14:11:28 -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 XAA28226 for ; Sun, 28 Nov 1999 23:11:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA59767 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 23:11:20 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5905214BEE for ; Sun, 28 Nov 1999 14:11:14 -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 OAA26244 for ; Sun, 28 Nov 1999 14:11:13 -0800 (PST) Date: Sun, 28 Nov 1999 14:11:13 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: kernel entry costs. 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 Peter wrote: > > Matt wrote: > > :(Julian wrote...) > > : > > :Am I also right in assuming that all the registers that the user was > > :running when they did the KERNCALL have been saved on the KERNEL stack by > > :the time that the above routines are called? > > : > > :(It's a pitty because if they were saved on the USER stack before the > > :kernel switched to the kernel stack it would have a great simplifying > > :effect on kernel threads support :-) (I know that could lead to traps > > :during saving the context but..) > > [..] > > Julian, you shouldn't worry about userland<->kernel context switchso much. > > The overhead for going into the kernel and coming out again, if all the > > cruft is removed, is *very* tiny -- it's almost like a subroutine call. > > I was rather suprised when I found out just how expensive kernel entry was > some time ago.. What I was doing was a reentrant syscall that aquired no > locks and ran about 5 instructions in kernel context.. Anyway, it took > something like 300 times longer to do that (called via int $0x81) than to > do a 'call' to equivalent code in userland. Anyway, with overheads on that > scale, whether we push 5 or 8 or whatever registers in the handler is > almost lost in the noise. > So I don't have my Intel books here, but My take on it is that the following happens: the IDT vercor is read leading to the Interrupt gate that must be read, leading to the loading of the code and stack segment registers, and a new SP and IP (PC), and resetting of processor 'ring' related stuff. The Old SP is saved on the new Stack. (Where does it store the old IP?) it then throws on the interrupt number and such and our routine saves all the registers and the other segment registers. the new segment registers are then loaded. The generic syscall code is called, and the appropriate function is selected and called. (This does not include any Ktrace stuff) on return, the return values are saved into the registers in a towers of hanoi simulation as the registers are reloaded and the segment registers are reloaded. Then the flags , SP and IP are reloaded. this is not an insignificant amount of work! Now that we have the vmware runnng, can we single step FreeBSD kernel through this and see what it actually goes through? that would be a fun thing to do :-) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 14:28:42 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 3AB7F14BD0 for ; Sun, 28 Nov 1999 14:28:39 -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 XAA28492 for ; Sun, 28 Nov 1999 23:28:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA59884 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 23:28:37 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CCC614BD0 for ; Sun, 28 Nov 1999 14:28:01 -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 OAA26450 for ; Sun, 28 Nov 1999 14:28:00 -0800 (PST) Date: Sun, 28 Nov 1999 14:28:00 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Which is the truth? (sycalls and traps) (fwd) 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 Peter says: :I was rather suprised when I found out just how expensive kernel entry was :some time ago.. What I was doing was a reentrant syscall that aquired no :locks and ran about 5 instructions in kernel context.. Anyway, it took :something like 300 times longer to do that (called via int $0x81) than to :do a 'call' to equivalent code in userland. Anyway, with overheads on that :scale, whether we push 5 or 8 or whatever registers in the handler is :almost lost in the noise. : :Cheers, :-Peter Matt says: Well, it could be 300x but that's like comparing a cache hit to a cache miss - in real terms a UP syscall takes, what, 1-3 uS? An SMP syscall takes 6 uS. This on a PIII-450. Both times can be cut down to less then 500nS with fairly simple optimizations. Unless you are doing hundreds of thousands of context switches a second the overhead is in the noise in real terms, and *definitely* in the noise if you tack on a task switch in the middle of that. Having the kernel do the context switch between threads has a huge number of advantages that should outweight or at least equal the minor increase in overhead. A couple of points that have been brought up in recent emails: * blockages due to VM faults All vm faults that do not occur with the Sp in the UTS's stack (a quick way of finding out if the UTS is running) can be telegraphed to the UTS, which should be able to schedule another thread. (If the UTS is running then we just block the entire process) * blockages due to file I/O (not even network I/O) there is no need for this to require The kernel to do this. The UTS can be notified and schedule a new task with a lot more knowledge of what is needed than the kernel can. of course there si always the case of co-operative scheduling, where teh UTS decides and the kernel 'does'. * disk parallelism (thread A reads file block from kernel cache, thread B reads file block and has a cache miss). Once again I don't think this required the kernel to do the change. * event synchronization what events? * kernel state Kernel state? Kernel state is probably going to be associated with the process, and not with teh KSEs that are sharing its quantum. Even if one were to use an asynchronous call gate one then has to deal with the additional overhead imposed by the asynch call gate when a syscall could have been run from the disk cache (that is, not block). Personally speaking, I think async call gates are a huge mistake without a prioritized, vectorable software interrupt mechanism to go along with it. The current unix signal mechanism is simply not up to the task. I don't think there is too much overhead...a copyout() of the syscall return values. There are serious issues with async call gates including potential resource hogging issues that frankly scare the hell out of me. I would prefer a kernel stack for each thread and I would prefer a syscall to set a thread runnable/not-runnable. Such a syscall could specify an optional cpu and optional run interval. You don't need a system stack for a thread that is not doing IO. you only need to keep one available per thread that enters the kernel. Wheen the thread enters userspace again, you can keep the same stack hanging around. If the thread in user space chages, and the new thread does a syscall, then it comes back and you still have the same stack sitting around.. 1 stack, N threads.. Until one blocks. then you grab a new one. (or block if you can't but you should keep a cache of them sitting around.. Most threading programs that have thousands of threads don't use them to do IO but to implement active objects or some sort. They expect the thread-switch overhead to be minuscule, and they can probably make do with 10 KSEs fro 1000 threads. There are simply too many things that a UP scheduler does not have access to - such as knowing whether a syscall can complete without blocking or not - to allow the UP scheduler to actually perform the context switch. You don't care if it is GOING to block.. you handle that when it happens. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 14:33:27 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 E227814C1E for ; Sun, 28 Nov 1999 14:33:22 -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 XAA28598 for ; Sun, 28 Nov 1999 23:33:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA59918 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 23:33:21 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C3D2B156D6 for ; Sun, 28 Nov 1999 14:32:53 -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 OAA26506; Sun, 28 Nov 1999 14:32:50 -0800 (PST) Date: Sun, 28 Nov 1999 14:32:50 -0800 (PST) From: Julian Elischer To: "Richard Seaman, Jr." Cc: arch@freebsd.org Subject: syscall overhead. In-Reply-To: <19991128111949.O1408@tar.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 Sun, 28 Nov 1999, Richard Seaman, Jr. wrote: > FYI, some measurements I did with the Linuxthreads "port" (ie. > native FreeBSD kernel threads using the linux threads code) on a > 266Mhz AMD processor showed the ability to do about 150,000 > kernel thread context switches/sec. The threads didn't do anything > other than context switch, so a "real world" context switch might > be slower, and the rate varies somewhat with the number of threads. > This was uniprocessor, not SMP. > > This suggests that kernel thread context switches, to have a measureable > impact on performance at even the 1% level, have to be occurring > at the rate of 1,500/sec or more. With a faster processor, and > the optimizations you suggest, I'm sure you might well be talking > 10,000 switches/sec to matter. > > I don't have any threaded apps that come close to this, but perhaps > they exist. And, unless you can fix the "user thread" scheduler so > it doesn't make any syscalls, its hard to see much of an advantage > for user thread context switches over kernel thread context switches, > from a performance standpoint. (The current user thread scheduler > can actually be slower at context switches that kernel threads, > because of the nubmer of syscalls it makes). > yes but have we catalogued those calls? I am guessing that we can probably get rid of a lot of them by appropriate kernel support. For example threads blocking and unblocking signals for various reasons.. I'm certain we could do the same lazy blocking that the kernel presently does So that blocking a signal would be simply a case of setting a bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 14:38:53 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 E985F1535E for ; Sun, 28 Nov 1999 14:38:49 -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 XAA28646 for ; Sun, 28 Nov 1999 23:38:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA59972 for freebsd-arch@freebsd.org; Sun, 28 Nov 1999 23:38:48 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 7CEBD1535E for ; Sun, 28 Nov 1999 14:38:41 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id QAA30084; Sun, 28 Nov 1999 16:38:38 -0600 (CST) (envelope-from dick) Date: Sun, 28 Nov 1999 16:38:38 -0600 From: "Richard Seaman, Jr." To: Julian Elischer Cc: "Richard Seaman, Jr." , arch@freebsd.org Subject: Re: syscall overhead. Message-ID: <19991128163838.A29767@tar.com> References: <19991128111949.O1408@tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Nov 28, 1999 at 02:32:50PM -0800, Julian Elischer wrote: > > I don't have any threaded apps that come close to this, but perhaps > > they exist. And, unless you can fix the "user thread" scheduler so > > it doesn't make any syscalls, its hard to see much of an advantage > > for user thread context switches over kernel thread context switches, > > from a performance standpoint. (The current user thread scheduler > > can actually be slower at context switches that kernel threads, > > because of the nubmer of syscalls it makes). > > > > yes but have we catalogued those calls? Not me, but it's not hard. > I am guessing that we can probably get rid of a lot of them by appropriate > kernel support. For sure. Its interesting, but I think good "user threads" needs a lot more kernel support than pure "kernel threads". The real question, which might really make a difference, is can you get rid of *all* syscalls for at least some subset of the UTS context switches. I don't think you can get rid of at least one syscall in at least some cases. > For example threads blocking and unblocking signals for various reasons.. > I'm certain we could do the same lazy blocking that the kernel > presently does So that blocking a signal would be simply a case of > setting a bit. Or, as another example, is there a way to implement shared scheduling information between the kernel and the UTS without a syscall for every bit of shared information. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 15:43:41 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 D615314A12 for ; Sun, 28 Nov 1999 15:43:35 -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 AAA29453 for ; Mon, 29 Nov 1999 00:43:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA60256 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 00:43:19 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A5B4E153AC for ; Sun, 28 Nov 1999 15:42:47 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40344>; Mon, 29 Nov 1999 10:35:30 +1100 Content-return: prohibited Date: Mon, 29 Nov 1999 10:42:42 +1100 From: Peter Jeremy Subject: Re: Which is the truth? (sycalls and traps) (fwd) In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov29.103530est.40344@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-29 09:28:00 +1100, Julian Elischer wrote: >(If the UTS is running then we just block the entire process) This could easily become a bottleneck on a large SMP system. I don't believe the kernel scheduler should need to obtain an SMP lock for its entire execution. Requiring this for a UTS sounds like a performance hit. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 15:49:35 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 BBD4714A12 for ; Sun, 28 Nov 1999 15:49:33 -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 AAA29513 for ; Mon, 29 Nov 1999 00:49:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA60305 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 00:49:32 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 85C1314A12 for ; Sun, 28 Nov 1999 15:49:19 -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 PAA27530; Sun, 28 Nov 1999 15:49:17 -0800 (PST) Date: Sun, 28 Nov 1999 15:49:17 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <384132CD.91D3C180@vigrid.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 Sun, 28 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > look at: > > http://www.freebsd.org/~julian/threads > > What is the typical pattern of processes blocked on I/O, especially > in a loaded system? Are there many tsleep/wakeups per I/O request, or > are there usually just one or two tsleep/wakeup pairs? On servers the usual action is for Disk or File IO for disk IO you block while the DMA happens to your userspace, and then you return. There is a possibility that you might block prior to the IO if you need to fault in some pages to put the dta into. For File IO, you don't block at allif the data is in cache, and you block once if it is not. Once again you MAY block prior to the IO if the pages are not in your address space, but in both these cases that is unlikely in a running server (though quite common in startup). > > I can see that it would be advantageous to have the kernel automatically > try to complete unblocked KSEs. But it needs to track the time spent > in the system for each KSE, so that its respective thread doesn't starve > other threads. Do we also want to place a limit on how much of the > _process_ quantum is used to complete unblocked KSEs? For Disk IO, when the thread is awakened, the IO has already completed (DMA) so there is not much to do. Letting it complete just is a matter of returning through all the layers and returning the status. For File IO, it will (on a read) need to copy the buffer out to user space. But that tends to be a pretty high priiority item.. you usually are waiting on that data. > > What if we have the UTS dole out time to be used for completing > unblocked KSEs? If there are no runnable higher priority threads, > the UTS can say "here's some time, try to complete as many of the > unblocked KSEs that you can". The kernel can use that time all at > once, piecemeal, or until the UTS says "your time is revoked, I have > higher priority threads". Or what if we have a 'process priority'. KSE's below the given priority will not be scheduled until the priority is dropped below that point. (becoming idle is effectivly dropping your priority. This would require setting a priority in the IO completion block or somewhere. > > Here's where I get into difficulty.. shoul d we notify the > > UTS on unblocking, or on completion? or both? > > Yeah, that's a tough question to answer. Perhaps we should take a > simple approach for now, and try to expand on it and optimize it > later. I think the simple solution is to notify the UTS and let > it decide when to resume it. Once that's working, we can look at > optimizing it so that the kernel can somehow try to automatically > complete unblocked KSEs. Since the UTS knows which KSE is being > run/resumed, tracking of time spent completing unblocked KSEs > can also be added later. My $.02, FWIW. My default answer would be to let the kernel code do basically what it does now, which is that the next time the scheduler looks at the (sub)process structure, ie is about to schedule the process, it would runthrough all the waiting KSE's and let them complete their kernel work. Some may simply block again so nothing lost, and others may wind up their stack back to the user/kernel boundary. I'd stop them at the boundary to collect a bunch of results I think. What do we do when a KSE becomes unblocked when the process in question is already running? Do we pre-empt? when? at the next sycall or kernel crossing? (like a signal)? or can we literally bust in and let it complete back to the kernel boundary? Certainly we could not do #2 if the other KSE is active in the kernel, but if its in userspace, it's a viable alternative. > > > > > > > o At the request of the scheduler, the kernel schedules a timeout for > > > the new quantum and resumes the now unblocked thread. > > > > define " the kernel schedules a timeout for > > the new quantum and resumes the now unblocked thread" > > When the UTS is informed that a thread is now unblocked in the > kernel (to the point that it can return to userland), and now > wants to resume the thread, the UTS will compute the time in which > a scheduling signal/upcall should be performed. It makes a system > call that both resumes the thread and schedules the signal. This assumes that you are doing pre-emptive multi threading in user land, using signals as the sheduler tick. > Under your different syscall gate, this would be a longjmp followed > by a call to schedule a signal. But if we're going to make a > system call anyways, why not switch to the resumed thread and > schedule the signal all at once? If the point of a different > syscall gate is to eliminate a system call to resume an unblocked > thread, then my contention is that we still have to make a system > call for a scheduling signal/upcall. Combine the resumption of the that's assuming you are using signals. Most threads packages I've used have not used them. teh threads co-operate and either are of limited duration in activity, (after which they block on some event) or are IO driven. > thread and the scheduling of the signal (thr_resume_with_quantum), > and you don't need a different syscall gate ;-) bleah.. signals.. :-( If you are going to make signals compulsary then you might as well go the whole way and let the kernel keep the userland contexts as well. Which is Matt's suggestion. Most of the "megga threads' projects I know of don't use signals. Threads is just a 'way of getting co-porcesses' > > Dan Eischen > eischen@vigrid.com > so, do the pictures help? Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16: 1: 1 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 1403215176 for ; Sun, 28 Nov 1999 16:00:55 -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 BAA29715 for ; Mon, 29 Nov 1999 01:00:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60359 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:00:54 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 1B19F15176 for ; Sun, 28 Nov 1999 16:00:50 -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 QAA27715; Sun, 28 Nov 1999 16:00:42 -0800 (PST) Date: Sun, 28 Nov 1999 16:00:42 -0800 (PST) From: Julian Elischer To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Which is the truth? (sycalls and traps) (fwd) In-Reply-To: <99Nov29.103530est.40344@border.alcanet.com.au> 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 Mon, 29 Nov 1999, Peter Jeremy wrote: > On 1999-Nov-29 09:28:00 +1100, Julian Elischer wrote: > >(If the UTS is running then we just block the entire process) > > This could easily become a bottleneck on a large SMP system. I don't > believe the kernel scheduler should need to obtain an SMP lock for its > entire execution. Requiring this for a UTS sounds like a performance > hit. > If the Scheduler itself had a pagefault, the last thing you want to do is make an upcall to the scheduler! Since the schedular is constantly active this would probably only happen during startup. Though in scheduling a long asleep thread, it's stack may be out on swap. You'd need to work out a way of 'pre-faulting' in the thread's context so that the scheduler didn't block trying to load it. or at least scheduling it in a way that allowed the fault to not be charged against the scheduler, but rather against the thread. The second may actually not be too hard. Julian > Peter > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16:18:56 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 8458714BC3 for ; Sun, 28 Nov 1999 16:18:53 -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 BAA29832 for ; Mon, 29 Nov 1999 01:18:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60427 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:18:53 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 6478414BC3 for ; Sun, 28 Nov 1999 16:18:42 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40352>; Mon, 29 Nov 1999 11:11:17 +1100 Content-return: prohibited Date: Mon, 29 Nov 1999 11:15:41 +1100 From: Peter Jeremy Subject: Re: Threads stuff In-reply-to: <38417A7F.B23C701D@vigrid.com> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov29.111117est.40352@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> <38417A7F.B23C701D@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-29 05:54:55 +1100, Daniel M. Eischen wrote: >Do we really want to be able to bind a _thread_ to a CPU? Yes. > Wouldn't it be sufficient to be able to bind a process to a CPU? Not really. If a process has multiple threads, it makes sense to be able to specify CPU affinity for each thread, since each thread can be scheduled independently. If you've got a multi-threaded process, I'm not sure why you'd want to bind it as a whole to a single CPU. This implies that only one thread can ever execute at once - which removes one major use for threads. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16:22:19 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 4A92114DD0 for ; Sun, 28 Nov 1999 16:22:14 -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 BAA29863 for ; Mon, 29 Nov 1999 01:22:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60452 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:22:05 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 32A9714DD0 for ; Sun, 28 Nov 1999 16:21:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA47007; Sun, 28 Nov 1999 16:21:52 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 16:21:52 -0800 (PST) From: Matthew Dillon Message-Id: <199911290021.QAA47007@apollo.backplane.com> To: Peter Jeremy Cc: freebsd-arch@freebsd.org Subject: Re: Threads stuff References: <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> <38417A7F.B23C701D@vigrid.com> <99Nov29.111117est.40352@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On 1999-Nov-29 05:54:55 +1100, Daniel M. Eischen wrote: :>Do we really want to be able to bind a _thread_ to a CPU? : :Yes. : :> Wouldn't it be sufficient to be able to bind a process to a CPU? : :Not really. If a process has multiple threads, it makes sense to be :able to specify CPU affinity for each thread, since each thread can :be scheduled independently. : :If you've got a multi-threaded process, I'm not sure why you'd want to :bind it as a whole to a single CPU. This implies that only one thread :can ever execute at once - which removes one major use for threads. : :Peter And unless the cpu is reserved, the best that you can do in a general purpose system (or in a system running several multi-threaded applications) is to bind a thread to a 'virtual' cpu. For most purposes, you simply want to supply a hint to the kernel rather then actually try to enforce a hard requirement. A UTS can supply the hint, but cannot actually do the physical assignment without a ridiculous amount of complexity. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16:23: 7 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 507C31506A for ; Sun, 28 Nov 1999 16:22:57 -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 BAA29878 for ; Mon, 29 Nov 1999 01:22:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60474 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:22:56 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9FF7A1506A for ; Sun, 28 Nov 1999 16:22:47 -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 QAA27988; Sun, 28 Nov 1999 16:22:46 -0800 (PST) Date: Sun, 28 Nov 1999 16:22:46 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <199911281721.JAA45015@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 Mat commnets on N KSEs for M threads: On Sun, 28 Nov 1999, Matthew Dillon wrote: > > :> > Advantages: > > * Kernel stack sharing by multiple threads in the non-blocking case, > which can lead to better memory and cache resource utilization. > > * An infinite number of threads can be created as long as they do not > all need a kernel stack simultaniously. > > * Kernel management issues are complex, but not terribly so. For > example, you have a thousand threads and they all suddenly decide > to block inside the kernel - the kernel needs a mechanism to > disallow kernel entry (setup the thread to force a restart of the > system call and then switch threads because no KSE resources are > available). The UTS can know its limit on KSEs and simply catch them on the way down. Count them at the door like a night club bouncer.. one out, one in.. :-) > > Problems: > > * You have to manage dynamic allocation and deallocation of KSE's > (verses simply preassigning one per thread). > I don't think this is too hard, and we may endup using the same code in things like interrupt handler threads. :-) > * 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. programmer error? In the current world, a programmer may decide to fork 1000000 times too. > > * 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). No the blocked thread 'returns' to the UTS, notifying it of its blocking. There has to be a UTS no matter what, even if it's copntrolling the thread contexts by remote control in the kernel (yur suggestion). If the context is all in user memory, it's pageable. In the kernel it's wired kernel memory.. which is more valuable? > * 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 have upcalls for these events. (see the paper on Scheduler activations) > > * 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. > Our solution is that you assign threads to subprocesses, and subprocesses are assigned to a processor. A thread that is not running can be assigned to a new subprocess by sumply changing the list it is on. > 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. that is unlikely to occur. I would assume that any thread library would get that memory wired down and it would be being touched all the time anyhow. > > 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. We are rforking to make subprocs. a subproc runs at one priority on one CPU. it has it's struct proc, (or most of one :-) and the threads are assigned to it. Any KSE that is created is automatically hung off that subproc. it will ony be run on that cpu unles there is intervention. (of which there may be may types, fro example a related subproc may be totally idle at teh time a KSE becomes unblocked.. it would be a waste to not use that other CPU) > > * Second, KSE management. The kernel has a limited number of KSE's > available and cannot allow any one process (containing multiple > threads) to hog them. > > KSE management must be dynamic on-entry. This means that when a > thread makes a system call and enters the kernel, the kernel must > make a determination in regards to the availability of KSE's. If > insufficient KSE's are available (or the process is using too many > already), the kernel must setup the thread to restart the system > call, deschedule it, and switch to another thread. The UTS could do the same thing.. and there has to be a UTS of some sort. > > i.e. there is always a 'current KSE' for a running thread, but if > it is the last one and the system call MIGHT block, the kernel > cannot afford to allow the thread to block in the one remaining > KSE and must deschedule the thread until KSEs are available to > handle the system call. > > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16:30:50 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 EC7DB1506A for ; Sun, 28 Nov 1999 16:30:48 -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 BAA29919 for ; Mon, 29 Nov 1999 01:30:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60502 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:30:47 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0E25E1506A for ; Sun, 28 Nov 1999 16:30:38 -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 QAA28107; Sun, 28 Nov 1999 16:30:35 -0800 (PST) Date: Sun, 28 Nov 1999 16:30:35 -0800 (PST) From: Julian Elischer To: peter.jeremy@alcatel.com.au Cc: freebsd-arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <99Nov29.111117est.40352@border.alcanet.com.au> 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 I think there is confusion here.. The way Dan and I have been discussing it (you need to go back and read the old mail) the process creates several thread classes. Thread classes can be bound to a CPU and can have different system priorities. They are implemted in FreeBSD by rfork()ing a new process (called a subprocess. The scheduler then assigns threads to the subprocess. Effectively assigning them to a class. if the class is "all threads herein run on CPU1" tehn you get what you want.. Dan left of the "sub". Julian On Mon, 29 Nov 1999, Peter Jeremy wrote: > On 1999-Nov-29 05:54:55 +1100, Daniel M. Eischen wrote: > >Do we really want to be able to bind a _thread_ to a CPU? > > Yes. > > > Wouldn't it be sufficient to be able to bind a process to a CPU? > > Not really. If a process has multiple threads, it makes sense to be > able to specify CPU affinity for each thread, since each thread can > be scheduled independently. > > If you've got a multi-threaded process, I'm not sure why you'd want to > bind it as a whole to a single CPU. This implies that only one thread > can ever execute at once - which removes one major use for threads. > > Peter > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 16:48:32 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 1132D1523B for ; Sun, 28 Nov 1999 16:48:29 -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 BAA00164 for ; Mon, 29 Nov 1999 01:48:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA60554 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 01:48:28 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4555F1523B for ; Sun, 28 Nov 1999 16:48:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA47070; Sun, 28 Nov 1999 16:48:20 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 16:48:20 -0800 (PST) From: Matthew Dillon Message-Id: <199911290048.QAA47070@apollo.backplane.com> To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> * Kernel stack sharing by multiple threads in the non-blocking case, :> which can lead to better memory and cache resource utilization. :> :> * An infinite number of threads can be created as long as they do not :> all need a kernel stack simultaniously. :> :> * Kernel management issues are complex, but not terribly so. For :> example, you have a thousand threads and they all suddenly decide :> to block inside the kernel - the kernel needs a mechanism to :> disallow kernel entry (setup the thread to force a restart of the :> system call and then switch threads because no KSE resources are :> available). : :The UTS can know its limit on KSEs and simply catch them on the way :down. Count them at the door like a night club bouncer.. one out, one in.. ::-) This isn't necessarily useful for the UTS to know. The UTS needs a virtual cpu resource 'environment' and should not have to know anything beyond that. So, for example, the number of cpu's you tell the UTS it owns does not have to be the same as the number of actual cpu's in the system or even the number of cpu's you intend to schedule it across. :> Problems: :> :> * You have to manage dynamic allocation and deallocation of KSE's :> (verses simply preassigning one per thread). :> : :I don't think this is too hard, and we may endup using the :same code in things like interrupt handler threads. :-) In the scheme I am thinking of, an interrupt handler thread can simply be a KSE associated with a single 'kernel' special 'process'. :> * 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 :... : :programmer error? :In the current world, a programmer may decide to fork 1000000 times too. In the world of threads the situation is different. Certain programming problems are best implemented if you can assume a huge number of available 'threads'. We have to make the concious decision to either support or not support such environments. I believe it would be possible to support such environments using the dynamic KSE concept so while I do not in general like the idea of dynamic KSE's, I'm willing to go along with it if we can find a sensibile way to implement them. Also keep in mind that we may, years down the line, wish to expand the environment to support massively parallel computing - cross platform computing. In such environments several hundred thousand threads is not uncommon. :> * 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. :... : :No the blocked thread 'returns' to the UTS, notifying it of its blocking. :There has to be a UTS no matter what, even if it's copntrolling the :thread contexts by remote control in the kernel (yur suggestion). :If the context is all in user memory, it's pageable. In the kernel it's wired kernel memory.. which is more valuable? Well, if you do this you are doubling your context switch overhead. It may work for system calls but will definitely not work for faults or other potential blockages without adding a lot of complexity. Considering the fact that programs use mmap() more and more heavily, having to deal with faults is a major consideration. :> such as VM faults, and cannot schedule around such things itself. :> This can lead to non-deterministic operation. : :The UTS can have upcalls for these events. (see the paper on :Scheduler activations) Yes, I understand where you are coming from. I believe the scheme to be too complex, however. Hmm. Let me restate that: I think the kernel ought to have the support for a UTS, but that it should not be required for native thread support to function. The kernel should be able to support threads natively without a UTS simply because most threaded applications will not need the added sophistication. This isn't to say that the UTS is entirely absent, only that it need not function in the heavy-handed complex way you've described in most cases and can simply be a simpler skeleton that keeps track of the threads. :> better able to actualy get the thread running deterministically :> because the userland scheduler might end up 'stuck' in a VM :> fault or something similar. : :that is unlikely to occur. :I would assume that any thread library would get that memory wired down :and it would be being touched all the time anyhow. Maybe, maybe not. It is an added complication and should not be required for the kernel to operate. Requiring wired down memory for proper operation is *bad* in many cases. If multi-threaded applications become ubiquitous, requiring wired down memory eats a valuable resource for idle processes (unless even more complexity is added to deal with that case on top of the complexity that already exists) :> * 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. : :We are rforking to make subprocs. a subproc runs at one priority on one CPU. :it has it's struct proc, (or most of one :-) and the threads are assigned :to it. Any KSE that is created is automatically hung off that subproc. :it will ony be run on that cpu unles there is intervention. :(of which there may be may types, fro example a related subproc may be totally idle at teh time a KSE becomes unblocked.. it would be a waste to not use that other CPU) This seems like an added unnecessary complication that would be difficult to scale dynamically to different topologies. Or, put another way, the burden of knowledge is much greater with this scheme then with other schemes. You already have KSE's, that's all the execution environment you really need. The KSE's will have an associated process, but the kernel is able to schedule KSE's across available cpu's even if several are associated with the same process. Every *active* thread needs to have an active KSE associated with it in order to handle faults, even if it is not currently in a system call, which means that it is the KSE's the kernel associates with a cpu, not a process. Runnable (but not active) threads do not need KSE's associated with them if they are not in the midst of a system call. An outline of my scheme would simply be: * You have a process, the process has threads * Each thread has a kernel Thread (or Task) structure associated with it. * KSE's are assigned to threads as needed, with only two cases that *require* a KSE assignment. (1) When the thread is currently running on a cpu, a KSE must be assigned to it even if the KSE's stack is not being used at the moment. Reasoning: So the kernel can preemptively switch away from the thread, take interrupts, faults, and other things. (2) When the thread is blocked in a system call, a KSE must be assigned to it to hold the kernel stack state. If you do things this way then the implementation within the kernel becomes trivial. The kernel scheduler only needs to know about KSE's and MMU contexts (extracted from the associated struct proc), and that's it. You can still impose scheduling requirements via a UTS by having the UTS give 'hints' to the kernel, but the UTS would not be *synchronously* required to wakeup a thread or put it to sleep. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:16:43 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 3B3C515433 for ; Sun, 28 Nov 1999 17:16:40 -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 CAA01579 for ; Mon, 29 Nov 1999 02:16:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60666 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:16:39 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8C85F15433 for ; Sun, 28 Nov 1999 17:16:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA47293; Sun, 28 Nov 1999 17:16:04 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 17:16:04 -0800 (PST) From: Matthew Dillon Message-Id: <199911290116.RAA47293@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> <38417A7F.B23C701D@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 ;-) I think this is a big mistake. Scheduling is already a big issue with KSE's, there is absolutely no need to make it even more complex by having two scheduling entities -- processes and KSE's when you only really need to have one -- the KSE's. We already have to associate kernel state with KSE's, which means we already have to schedule KSE's. We want maximum parallel execution within the kernel (once the MP lock becomes fine grained), and we should not have to rfork() to get it. There is absolutely no reason why KSE's associated with the same process cannot be run in parallel, which means that you might as well use KSE's as your scheduling entity rather then processes. By attempting to use a process as your scheduling entity you create a very complex scheduling situation whereby the kernel threads require completely different code to support then the user threads. I'd rather have the same code control both - it's easier in concept, design, and implementation. There are many, many advantages to using a KSE as your scheduling entity. You can assign a floating KSE to each cpu and associate it with the currently running thread. When a context switch occurs, if the KSE's stack is not in use (i.e. the thread was not blocked in a system call), you can use the *same* KSE for the next running thread on that cpu. The result is massive L1/L2 cache sharing for the kernel stack to the point where you don't even need a kernel stack pre-assigned for your long-idle processes in some cases (restartable system call case). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:19:58 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 A6D90153FB for ; Sun, 28 Nov 1999 17:19:55 -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 CAA01864 for ; Mon, 29 Nov 1999 02:19:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60688 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:19:54 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A6F32153FB for ; Sun, 28 Nov 1999 16:53:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA47117; Sun, 28 Nov 1999 16:53:27 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 16:53:27 -0800 (PST) From: Matthew Dillon Message-Id: <199911290053.QAA47117@apollo.backplane.com> To: Julian Elischer Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I think there is confusion here.. : :The way Dan and I have been discussing it (you need to go back and read :the old mail) the process creates several thread classes. Thread classes :can be bound to a CPU and can have different system priorities. They are :implemted in FreeBSD by rfork()ing a new process (called a subprocess. :The scheduler then assigns threads to the subprocess. Effectively :assigning them to a class. :if the class is "all threads herein run on CPU1" tehn you get what you :want.. :Dan left of the "sub". : :Julian Why assign classes to processes when you can assign classes to KSE's? If you intend to have a UTS, the UTS must dynamically manage the runnability of the KSE's anyway so there isn't any real need to group them in their own rfork()'d processes. Since the KSE is the kernel's scheduling entity, not a process, it makes sense to concentrate the work in the KSE rather then complicate matters by grouping classes with rfork(). This does not prevent us from rfork()ing, it just makes rfork() unnecessary for thread management. There are plenty of other reasons why one might want to rfork() that have nothing to do with thread management so we obviously want to keep that functionality. If you concentrate the work in the KSE, the design becomes much, much simpler. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:20: 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 86E2815412 for ; Sun, 28 Nov 1999 17:19:55 -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 CAA01871 for ; Mon, 29 Nov 1999 02:19:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60702 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:19:55 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EE85415412 for ; Sun, 28 Nov 1999 16:54:38 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40340>; Mon, 29 Nov 1999 11:47:12 +1100 Content-return: prohibited Date: Mon, 29 Nov 1999 11:54:24 +1100 From: Peter Jeremy Subject: Re: Which is the truth? (sycalls and traps) (fwd) In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov29.114712est.40340@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Nov29.103530est.40344@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-29 11:00:42 +1100, Julian Elischer wrote: > >On Mon, 29 Nov 1999, Peter Jeremy wrote: > >> On 1999-Nov-29 09:28:00 +1100, Julian Elischer wrote: >> >(If the UTS is running then we just block the entire process) >> >> This could easily become a bottleneck on a large SMP system. I don't >> believe the kernel scheduler should need to obtain an SMP lock for its >> entire execution. Requiring this for a UTS sounds like a performance >> hit. > >If the Scheduler itself had a pagefault, the last thing you want to do is >make an upcall to the scheduler! True. On re-reading, I didn't read (or absorb) enough of the context :-(. I suspect what I said is still true, but I'm not sure how practical it would be to work around it. >Since the schedular is constantly active this would probably only happen >during startup. Depending on the way the scheduler is designed, this may not be true - potentially the code to handle an uncommon exception may have been paged out. Unless the UTS is given more privileges than a normal user process/thread, I can't see any easy way out of this: mlock() needs super-user privs, checking if a memory address is physically resident typically requires privileged instructions (or a syscall). > Though in scheduling a long asleep thread, it's stack may >be out on swap. You'd need to work out a way of 'pre-faulting' in the >thread's context so that the scheduler didn't block trying to load it. >or at least scheduling it in a way that allowed the fault to not be >charged against the scheduler, but rather against the thread. > >The second may actually not be too hard. I'm not sure I follow: If a thread dereferences a pointer to a non-resident page, how does the thread avoid blocking? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:20: 5 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 3601515432 for ; Sun, 28 Nov 1999 17:19:57 -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 CAA01879 for ; Mon, 29 Nov 1999 02:19:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60715 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:19:56 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BCC9F1547E for ; Sun, 28 Nov 1999 16:57:36 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt7.pcnet.net [206.105.29.81]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id TAA18456; Sun, 28 Nov 1999 19:57:37 -0500 (EST) Message-ID: <3841CFB4.F5B9A2BD@vigrid.com> Date: Sun, 28 Nov 1999 19:58:28 -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: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sun, 28 Nov 1999, Daniel M. Eischen wrote: > > What if we have the UTS dole out time to be used for completing > > unblocked KSEs? If there are no runnable higher priority threads, > > the UTS can say "here's some time, try to complete as many of the > > unblocked KSEs that you can". The kernel can use that time all at > > once, piecemeal, or until the UTS says "your time is revoked, I have > > higher priority threads". > > Or what if we have a 'process priority'. KSE's below the given priority will > not be scheduled until the priority is dropped below that point. > (becoming idle is effectivly dropping your priority. This would require > setting a priority in the IO completion block or somewhere. Or when the thread was scheduled via a system call... > > > > Here's where I get into difficulty.. shoul d we notify the > > > UTS on unblocking, or on completion? or both? > > > > Yeah, that's a tough question to answer. Perhaps we should take a > > simple approach for now, and try to expand on it and optimize it > > later. I think the simple solution is to notify the UTS and let > > it decide when to resume it. Once that's working, we can look at > > optimizing it so that the kernel can somehow try to automatically > > complete unblocked KSEs. Since the UTS knows which KSE is being > > run/resumed, tracking of time spent completing unblocked KSEs > > can also be added later. My $.02, FWIW. > > My default answer would be to let the kernel code do basically what it > does now, which is that the next time the scheduler looks at the (sub)process > structure, ie is about to schedule the process, it would runthrough all > the waiting KSE's and let them complete their kernel work. Some may > simply block again so nothing lost, and others may wind up their stack back > to the user/kernel boundary. I'd stop them at the boundary to collect a > bunch of results I think. Yes, and notify the UTS of all completed KSEs at once. We do need to keep system time accrued for each KSE also. > > What do we do when a KSE becomes unblocked when the process in question is > already running? Do we pre-empt? when? at the next sycall or > kernel crossing? (like a signal)? or can we literally bust in and let it > complete back to the kernel boundary? Certainly we could not do #2 if > the other KSE is active in the kernel, but if its in userspace, it's a > viable alternative. If the kernel is going to automatically complete KSEs, then I would only do it when new KSEs block or when the process is resumed. The UTS is timing the current thread, so you don't want to do work for other threads while the UTS is going to count it against the currently running thread. If the kernel is not automatically completing the KSEs, then the UTS can be notified of unblocked KSEs at any time. > > When the UTS is informed that a thread is now unblocked in the > > kernel (to the point that it can return to userland), and now > > wants to resume the thread, the UTS will compute the time in which > > a scheduling signal/upcall should be performed. It makes a system > > call that both resumes the thread and schedules the signal. > > This assumes that you are doing pre-emptive multi threading in user > land, using signals as the sheduler tick. Well, I was hoping to get a scheduling upcall instead of a signal, but yes. That's the way libc_r works now, and you need some clock tick type interruption so that threads don't run forever. Even if a thread is SCHED_FIFO, you still need to check for other timeouts like pthread_cond_timedwait(). > > Under your different syscall gate, this would be a longjmp followed > > by a call to schedule a signal. But if we're going to make a > > system call anyways, why not switch to the resumed thread and > > schedule the signal all at once? If the point of a different > > syscall gate is to eliminate a system call to resume an unblocked > > thread, then my contention is that we still have to make a system > > call for a scheduling signal/upcall. Combine the resumption of the > > that's assuming you are using signals. > Most threads packages I've used have not used them. > teh threads co-operate and either are of limited duration in activity, > (after which they block on some event) or are IO driven. I'm not assuming signals, upcalls would be preferred, but we do need to support the standards, and some form of scheduling signal or interruption will be needed. I think it will be difficult to remove all system calls from a thread switch, but I think it will be very easy to limit thread switches to one system call. > > thread and the scheduling of the signal (thr_resume_with_quantum), > > and you don't need a different syscall gate ;-) > > bleah.. signals.. :-( > If you are going to make signals compulsary then you might as well go the > whole way and let the kernel keep the userland contexts as well. > Which is Matt's suggestion. Like I said, I don't want signals; a scheduling upcall would be better. For threads blocked in the kernel, I don't see much of a problem with keeping the trapframe in the KSE since it's already on the kernel stack. I don't want to keep contexts of threads not blocked in the kernel, though. > so, do the pictures help? Yes, I understood them just fine :) I'm still not sold on the new syscall gate and IOCB, because I think we have to make at least one system call when threads are switched or resumed. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:34: 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 D529415412 for ; Sun, 28 Nov 1999 17:33:58 -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 CAA03344 for ; Mon, 29 Nov 1999 02:33:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60847 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:33:57 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A57115412 for ; Sun, 28 Nov 1999 17:33:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA47395; Sun, 28 Nov 1999 17:33:48 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 17:33:48 -0800 (PST) From: Matthew Dillon Message-Id: <199911290133.RAA47395@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <3841CFB4.F5B9A2BD@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :If the kernel is going to automatically complete KSEs, then I would only :do it when new KSEs block or when the process is resumed. The UTS is timing :the current thread, so you don't want to do work for other threads while :the UTS is going to count it against the currently running thread. If the :kernel is not automatically completing the KSEs, then the UTS can be notified :of unblocked KSEs at any time. The kernel *must* complete blocked KSE's or you run into a thousand potential system deadlock situations. We have no choice there. :... interesting stuff (removed) ... -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:37: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 95FB114C94 for ; Sun, 28 Nov 1999 17:37:41 -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 CAA03610 for ; Mon, 29 Nov 1999 02:37:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60874 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:37:40 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BA57D15469 for ; Sun, 28 Nov 1999 17:06:58 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA47262; Sun, 28 Nov 1999 17:06:57 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 17:06:57 -0800 (PST) From: Matthew Dillon Message-Id: <199911290106.RAA47262@apollo.backplane.com> To: Arun Sharma Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> <19991127205752.A7145@sharmas.dhs.org> <199911281641.IAA44909@apollo.backplane.com> <19991128102612.A8570@sharmas.dhs.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Sun, Nov 28, 1999 at 08:41:57AM -0800, Matthew Dillon wrote: :> I think we are already operating under the assumption that the current :> scheduler must be rewritten, or at least significantly modified. Amoung :> other things we have to get rid of all the extra junk that is in assembler :> that could easily be C (I seem to recall someone actually working towards :> that goal, was any of that ever committed? It seemed pretty good). : :Yes, that was commited. But I think it can be better. Right now, the code :goes from : :C -> asm (context switch out) -> C (pick a new process) -> asm (switch in) -> C : :I think it should be : :lock :C (pick a new process p) :asm (switch from curproc to p) :unlock : : -Arun Yes, I agree with you completely. Limiting the asm to just switch between two processes and throwing the rest into C is a good goal to have. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:37: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 9A4CF14CA6 for ; Sun, 28 Nov 1999 17:37:44 -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 CAA03622 for ; Mon, 29 Nov 1999 02:37:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60891 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:37:43 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B414514CA6 for ; Sun, 28 Nov 1999 17:07:50 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt7.pcnet.net [206.105.29.81]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id UAA19714; Sun, 28 Nov 1999 20:06:45 -0500 (EST) Message-ID: <3841D1D9.A048355D@vigrid.com> Date: Sun, 28 Nov 1999 20:07:37 -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: Julian Elischer Cc: peter.jeremy@alcatel.com.au, freebsd-arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > I think there is confusion here.. > > The way Dan and I have been discussing it (you need to go back and read > the old mail) the process creates several thread classes. Thread classes > can be bound to a CPU and can have different system priorities. They are > implemted in FreeBSD by rfork()ing a new process (called a subprocess. > The scheduler then assigns threads to the subprocess. Effectively > assigning them to a class. > if the class is "all threads herein run on CPU1" tehn you get what you > want.. > Dan left of the "sub". Right, so if you wanted to bind a _single_ thread to a CPU, you bind your chosen thread to a subprocess, and the subprocess to the CPU. I did leave out sub. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 17:37:59 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 9F659152BD for ; Sun, 28 Nov 1999 17:37:49 -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 CAA03630 for ; Mon, 29 Nov 1999 02:37:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA60899 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 02:37:48 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 82AF11541F for ; Sun, 28 Nov 1999 17:06:30 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40337>; Mon, 29 Nov 1999 11:59:05 +1100 Content-return: prohibited Date: Mon, 29 Nov 1999 12:06:13 +1100 From: Peter Jeremy Subject: Re: Threads stuff In-reply-to: To: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov29.115905est.40337@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <199911281721.JAA45015@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-29 11:22:46 +1100, Julian Elischer wrote: >No the blocked thread 'returns' to the UTS, notifying it of its blocking. >There has to be a UTS no matter what, even if it's copntrolling the >thread contexts by remote control in the kernel (yur suggestion). >If the context is all in user memory, it's pageable. In the kernel it's > wired kernel memory.. which is more valuable? For the UTS to function sensibly (and with maximum efficiency), it effectively has to be permanently resident as well - and permanently resident user memory is just as valuable as wired kernel memory :-). Admittedly, (most of) the UTS probably will wind up staying in-core anyway due to frequent use, and if it wind up paged out, its probably not as critical (except maybe to that process). That said, I'd like to see much of the kernel become pageable - but that is another can of worms. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 19:15:18 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 49F39151CE for ; Sun, 28 Nov 1999 19:15:15 -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 EAA07734 for ; Mon, 29 Nov 1999 04:15:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA61184 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 04:15:14 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C0C58151CE for ; Sun, 28 Nov 1999 19:15:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt45.pcnet.net [206.105.29.119]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA03824; Sun, 28 Nov 1999 22:15:07 -0500 (EST) Message-ID: <3841EFF2.667F105@vigrid.com> Date: Sun, 28 Nov 1999 22:16:02 -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: <3841CFB4.F5B9A2BD@vigrid.com> <199911290133.RAA47395@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: > > :If the kernel is going to automatically complete KSEs, then I would only > :do it when new KSEs block or when the process is resumed. The UTS is timing > :the current thread, so you don't want to do work for other threads while > :the UTS is going to count it against the currently running thread. If the > :kernel is not automatically completing the KSEs, then the UTS can be notified > :of unblocked KSEs at any time. > > The kernel *must* complete blocked KSE's or you run into a thousand > potential system deadlock situations. We have no choice there. The question is whether the kernel completes the KSEs automatically without direction from the UTS, or if the UTS is informed of the unblocking and later chooses to direct the kernel to complete the KSEs. The KSEs _will_ be completed, it's just who is directly responsible for their being completed. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 19:21:24 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 0BB6314A00 for ; Sun, 28 Nov 1999 19:21:21 -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 EAA07817 for ; Mon, 29 Nov 1999 04:21:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA61233 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 04:21:20 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D406314A00 for ; Sun, 28 Nov 1999 19:21:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA48755; Sun, 28 Nov 1999 19:21:00 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 19:21:00 -0800 (PST) From: Matthew Dillon Message-Id: <199911290321.TAA48755@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <3841CFB4.F5B9A2BD@vigrid.com> <199911290133.RAA47395@apollo.backplane.com> <3841EFF2.667F105@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon wrote: :> :> :If the kernel is going to automatically complete KSEs, then I would only :> :do it when new KSEs block or when the process is resumed. The UTS is timing :> :the current thread, so you don't want to do work for other threads while :> :the UTS is going to count it against the currently running thread. If the :> :kernel is not automatically completing the KSEs, then the UTS can be notified :> :of unblocked KSEs at any time. :> :> The kernel *must* complete blocked KSE's or you run into a thousand :> potential system deadlock situations. We have no choice there. : :The question is whether the kernel completes the KSEs automatically without :direction from the UTS, or if the UTS is informed of the unblocking and later :chooses to direct the kernel to complete the KSEs. The KSEs _will_ be :completed, it's just who is directly responsible for their being completed. : :Dan Eischen :eischen@vigrid.com The kernel must be able to complete the KSEs without UTS intervention or we risk seriously destabilizing our system. The completion of the KSEs does not necessarily have to wake the underlying thread up on return to user mode - that could be done through notification of the UTS. Or the UTS could simply flag the kernel that the underlying KSE can wake up the thread automatically (which I recommend as the default). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 19:42: 5 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 ABB6B150C3 for ; Sun, 28 Nov 1999 19:42:03 -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 EAA08072 for ; Mon, 29 Nov 1999 04:42:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA61321 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 04:42:02 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8902015463 for ; Sun, 28 Nov 1999 19:41:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt42.pcnet.net [206.105.29.116]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA06775; Sun, 28 Nov 1999 22:41:39 -0500 (EST) Message-ID: <3841F62C.3180BA54@vigrid.com> Date: Sun, 28 Nov 1999 22:42:36 -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: <3841CFB4.F5B9A2BD@vigrid.com> <199911290133.RAA47395@apollo.backplane.com> <3841EFF2.667F105@vigrid.com> <199911290321.TAA48755@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: > The kernel must be able to complete the KSEs without UTS intervention > or we risk seriously destabilizing our system. This is not the contention of the SA paper. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 21: 9:19 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 AC62E1512B for ; Sun, 28 Nov 1999 21:09:17 -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 GAA09265 for ; Mon, 29 Nov 1999 06:09:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA61563 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 06:09:15 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C3E491512B for ; Sun, 28 Nov 1999 21:09:09 -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 VAA31801; Sun, 28 Nov 1999 21:09:08 -0800 (PST) Date: Sun, 28 Nov 1999 21:09:08 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <199911290048.QAA47070@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 Sun, 28 Nov 1999, Matthew Dillon wrote: > :We are rforking to make subprocs. a subproc runs at one priority on one CPU. > :it has it's struct proc, (or most of one :-) and the threads are assigned > :to it. Any KSE that is created is automatically hung off that subproc. > :it will ony be run on that cpu unles there is intervention. > :(of which there may be may types, fro example a related subproc may be totally idle at teh time a KSE becomes unblocked.. it would be a waste to not use that other CPU) > > This seems like an added unnecessary complication that would be > difficult to scale dynamically to different topologies. Or, put another > way, the burden of knowledge is much greater with this scheme then with > other schemes. Think of the subprocs as "virtual processors" (your terminology) you would have one for each processor for maximum parallelism, but posibly a couple extra if you wanted a virtual processor that was to run at a higher priority > > You already have KSE's, that's all the execution environment you really > need. The KSE's will have an associated process, but the kernel is able > to schedule KSE's across available cpu's even if several are > associated with the same process. Every *active* thread needs to have > an active KSE associated with it in order to handle faults, even if it > is not currently in a system call, which means that it is the KSE's > the kernel associates with a cpu, not a process. Runnable (but not > active) threads do not need KSE's associated with them if they are not > in the midst of a system call. By hangling KSEs and threads off virtual procesors (rforked procs) you can do thread classes, which is one of the requirements we came to in the requirements phase. Subprocesses can have some processor affinity, and they have system-wide priority. > > An outline of my scheme would simply be: > > * You have a process, the process has threads I want to add rforked subprocesses here . this gice us classes. everywhere below where you say "process" I add a preceding "sub-" :-) > > * Each thread has a kernel Thread (or Task) structure associated > with it. We agree on this, just not entirely on which 'space' they live in. How do you set policy for a kernel thread schedular? > > * KSE's are assigned to threads as needed, with only two cases that > *require* a KSE assignment. > > (1) When the thread is currently running on a cpu, a KSE must be > assigned to it even if the KSE's stack is not being used at > the moment. > > Reasoning: So the kernel can preemptively switch away from the > thread, take interrupts, faults, and other things. exactly > > (2) When the thread is blocked in a system call, a KSE must be > assigned to it to hold the kernel stack state. exactly > > If you do things this way then the implementation within the kernel > becomes trivial. The kernel scheduler only needs to know about KSE's > and MMU contexts (extracted from the associated struct proc), and that's > it. You can still impose scheduling requirements via a UTS by having > the UTS give 'hints' to the kernel, but the UTS would not be > *synchronously* required to wakeup a thread or put it to sleep. > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 21:17:31 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 0563F153DD for ; Sun, 28 Nov 1999 21:17:29 -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 GAA09397 for ; Mon, 29 Nov 1999 06:17:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA61608 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 06:17:28 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 23492153DD for ; Sun, 28 Nov 1999 21:17:20 -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 VAA31924; Sun, 28 Nov 1999 21:17:18 -0800 (PST) Date: Sun, 28 Nov 1999 21:17:18 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <3841CFB4.F5B9A2BD@vigrid.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 Sun, 28 Nov 1999, Daniel M. Eischen wrote: > > > > bleah.. signals.. :-( > > If you are going to make signals compulsary then you might as well go the > > whole way and let the kernel keep the userland contexts as well. > > Which is Matt's suggestion. > > Like I said, I don't want signals; a scheduling upcall would be better. > For threads blocked in the kernel, I don't see much of a problem with > keeping the trapframe in the KSE since it's already on the kernel stack. > I don't want to keep contexts of threads not blocked in the kernel, though. a signal is just another upcall.. I'm using the terms interchangeably. > > > so, do the pictures help? > > Yes, I understood them just fine :) I'm still not sold on the new > syscall gate and IOCB, because I think we have to make at least one > system call when threads are switched or resumed. > I'm not completely sold on them either. I just have a gut feeling on it based on doing this for 25 years. > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 21:23:27 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 2E9B614A1E for ; Sun, 28 Nov 1999 21:23:24 -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 GAA09468 for ; Mon, 29 Nov 1999 06:23:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA61649 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 06:23:23 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 54A4414A1E for ; Sun, 28 Nov 1999 21:23:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA59334; Sun, 28 Nov 1999 21:23:17 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 21:23:17 -0800 (PST) From: Matthew Dillon Message-Id: <199911290523.VAA59334@apollo.backplane.com> To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> This seems like an added unnecessary complication that would be :> difficult to scale dynamically to different topologies. Or, put another :> way, the burden of knowledge is much greater with this scheme then with :> other schemes. : :Think of the subprocs as "virtual processors" (your terminology) : :you would have one for each processor for maximum parallelism, but :posibly a couple extra if you wanted a virtual processor that :was to run at a higher priority :... :> active) threads do not need KSE's associated with them if they are not :> in the midst of a system call. : :By hangling KSEs and threads off virtual procesors (rforked procs) you :can do thread classes, which is one of the requirements we came to in :the requirements phase. Subprocesses can have some processor affinity, :and they have system-wide priority. I just don't see it. You can do thread classes anyway, you don't have to put them under a 'process' umbrella. In fact, it seems to me that it would not be desireable to do so because it would mean that the UTS would have to schedule across process boundries (though not an MMU boundry) to attain maximum efficiency for the default threading class. A better solution would simply be to have a single process and give the kernel the ability to schedule threads to processors via their KSE's. The UTS can still setup whatever thread classes it likes, and can still control the scheduling of KSE's, but it would not need to dynamically create and delete process contexts on top of that. Additionally, the kernel's scheduler would only have to deal with KSE's rather then have to deal with processes + KSEs, and kernel threads would simply be KSE's associated with a dummy kernel 'process', again without having to write special code. Kernel interrupts would be able to do the same -- run the interrupt in a KSE and still attain maximum parallelism. And the kernel can place the threads associated with the process into a larger scheduling whole without having to special-case the priority calculations that occur when you start splitting things into separate processes. If you want a higher aggregate priority, you assign the process a higher priority no matter how many threads there are and no matter which scheduling class the threads are placed in relative to each other. You can *still* rfork() if you want, but the reasons for doing so become more deterministic then 'trying to simulate multiple cpu's'. All four mechanisms can be implemented by having the kernel scheduler deal only with KSE's. That's (1) one implementation handling four different mechanisms. If we do it your way we wind up writing three times the amount of code to deal with three different special cases, and that's assuming that kernel threads and interrupt threads can be folded together into the same entity. I see no advantage to doing things that way and I see no advantage to creating such a high level of 'base' complexity. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 21:37:48 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 938A61547C for ; Sun, 28 Nov 1999 21:37:46 -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 GAA09575 for ; Mon, 29 Nov 1999 06:37:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA61704 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 06:37:44 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6E6751547C for ; Sun, 28 Nov 1999 21:37:39 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA61862; Sun, 28 Nov 1999 21:37:39 -0800 (PST) (envelope-from dillon) Date: Sun, 28 Nov 1999 21:37:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911290537.VAA61862@apollo.backplane.com> To: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <199911290523.VAA59334@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Let me give you an example of how it would work if KSEs were the kernel scheduling entity instead of processes. (1) The UTS wants to run threads in a FIFO. - UTS schedules one thread at a time with the kernel. That is, it deschedules the current thread and schedules a new one. FIFO operation is achieved. (2) The UTS wants to run several threads in parallel - UTS schedules several threads at a time with the kernel. For example, the UTS can decide to schedule two threads with the kernel (not deschedule the first one after scheduling the second one). - UTS is thus able to simulate N cpu's, a 'virtual cpu environment' without having to run through loops with rfork() and exit(). - kernel memory and process 'clutter' is minimized. There is still only one process shown in the ps (or at least the base ps). (3) The UTS wants to simulate prioritized software interrupts using threads. - UTS simply deschedules the thread being interrupted and schedules the interrupting thread, and vise-versa on return. (4) The UTS wants to simulate a multi-priority RR queue. - UTS simply schedules all threads at the highest priority all at once and ensures that threads at lower priorities are descheduled. You see? It's easy. If you try to do this under a multiple-process umbrella using rfork() and enforce serialization on a process-by-process basis, you complicate matters greatly. For example, take the last algorithm -- N equi-priority threads need to be run with maximum parallelism. In the rfork() case the UTS code becomes much more complex then simply telling the kernel to 'go' with all N threads. The UTS must manage the spread across the virtual cpu's as well and must have direct knowledge of the number of cpu's in the system on top of that. But if the KSE is the schedulable entity and the UTS is simply trying to simulate N cpu's (where N can be anything -- including large numbers like 10 or 20), the UTS simply tells the kernel to 'go' for all N threads and lets the kernel deal with the conversion to actual physical cpu's. Similarly, reserving a physical cpu is also trivial. In this case just as trivial as reserving a 'virtual' cpu. A whole lot of code becomes a whole lot less complex if the KSE is the schedulable entity rather then the struct proc. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 28 22:14:38 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 5E6FA1527F for ; Sun, 28 Nov 1999 22:14:35 -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 HAA10034 for ; Mon, 29 Nov 1999 07:14:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA61826 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 07:14:34 +0100 (MET) Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 3E4F11527F for ; Sun, 28 Nov 1999 22:14:24 -0800 (PST) (envelope-from jburkhol@home.com) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 556731FD0 for ; Sun, 28 Nov 1999 22:14:24 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Subject: thread references Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Nov 1999 22:14:24 -0800 From: Jake Burkholder Message-Id: <19991129061424.556731FD0@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you can get to a solaris box, I think the following man pages are worth reading: _lwp_create(2) _lwp_cond_signal(2) _lwp_cond_wait(2) _lwp_continue(2) _lwp_makecontext(2) _lwp_wait(2) getcontext(2) makecontext(3c) ucontext(5) as well as /usr/include/sys/lwp.h I'd also like to point everyone to pages 350 through 352 of Volume 2 of the Intel Architecture Software Developer's manual, which describe in detail exactly what happens on entry to the kernel. The psuedo-code for the int instruction is quite long, inter-priviledge-level-interrupt is us. http://developer.intel.com/design/pentiumIII/xeon/manuals/ Thank you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 0: 6:49 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 EEF4414F41 for ; Mon, 29 Nov 1999 00:06:46 -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 JAA11562 for ; Mon, 29 Nov 1999 09:06:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA62209 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 09:06:45 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4A15514F41 for ; Mon, 29 Nov 1999 00:06:36 -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 AAA34147; Mon, 29 Nov 1999 00:05:36 -0800 (PST) Date: Mon, 29 Nov 1999 00:05:36 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: "Daniel M. Eischen" , arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <199911290116.RAA47293@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 Sun, 28 Nov 1999, Matthew Dillon wrote: > > :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 ;-) > > I think this is a big mistake. Scheduling is already a big issue with > KSE's, there is absolutely no need to make it even more complex by having > two scheduling entities -- processes and KSE's when you only really need > to have one -- the KSE's. Here is where you and I part company to some extent. A process must be limitted in CPU resources to teh same anount whether it be unthreaded, or threaded. If you want yuor 20 threads to be scheduled at teh same weighting as teh other processes then a process with 20 threads will have 20 times the scheduling clout as one with 1. Subprocesses are 'containers' of threads. a supprocess is scheduled in exactly the same way as other processes. Processes have priorities and can be 'nice'd etc. If two processes share a machine each gets half. If one of them is threaded, then how it divides up it's time is it's business,but the moment it's tick is finished, it's descheduled and so are any threads it had running.. This is crucial to being able to get the behaviour expected by the threading standards. If you want a bigger slice of the cake you need to abide by the same rules a s anormal process.. i.e. fork (rfork) and spread your work over two sets of quanta. If you want to utilise two processors, you should allocate two virtual processors (the same thing) If you don't you are competing unfairly with the other processes. It's not a 'big mistake'. I think it's almost a requirement. We need to group threads to a limiting larger entity. and we need that larger entity to define sheduling behaviour with regards to the reat of the system. guess what, we already have such an entity.. it's called a process. > > We already have to associate kernel state with KSE's, which means we > already have to schedule KSE's. We want maximum parallel execution within > the kernel (once the MP lock becomes fine grained), and we should not have > to rfork() to get it. You are forgetting that you must ASK for parallelism otherwise you are limitted to one process-worth of quanta. A process is limitted to one CPU-second per second. To allow you to automatically get more is unfaair on the other processes. You need to go through the same limits as they do, though we make it almos infinitly easier for you to do so. > > There is absolutely no reason why KSE's associated with the same process > cannot be run in parallel, which means that you might as well use KSE's > as your scheduling entity rather then processes. Except that that's not a goal. You are limitted to the virtual processors (your words) that you have. > > By attempting to use a process as your scheduling entity you create a > very complex scheduling situation whereby the kernel threads require > completely different code to support then the user threads. I'd rather > have the same code control both - it's easier in concept, design, and > implementation. no I disagree about the complexity.. if you wish to add the required contrraints directly upon KSEs and then make the m behave correctly With respect to other processes.. (i.e. limit themselves to their quanta) you will add back almost all of that complexity, except now you have written it as separate code. > > There are many, many advantages to using a KSE as your scheduling entity. > You can assign a floating KSE to each cpu and associate it with the > currently running thread. When a context switch occurs, if the KSE's > stack is not in use (i.e. the thread was not blocked in a system call), > you can use the *same* KSE for the next running thread on that cpu. The > result is massive L1/L2 cache sharing for the kernel stack to the point > where you don't even need a kernel stack pre-assigned for your long-idle > processes in some cases (restartable system call case). You dont assign a floating KSE to each processor, you assign one to each virtual processor, and guess what that is? Everything you say above is still true for that case. Especially if there is processor affinity for (sub)processes. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 0:25:29 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 E5D8815361 for ; Mon, 29 Nov 1999 00:25:27 -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 JAA11862 for ; Mon, 29 Nov 1999 09:25:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA62299 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 09:25:26 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 621AE152B4 for ; Mon, 29 Nov 1999 00:25:21 -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 AAA34386; Mon, 29 Nov 1999 00:25:18 -0800 (PST) Date: Mon, 29 Nov 1999 00:25:18 -0800 (PST) From: Julian Elischer To: Peter Jeremy Cc: freebsd-arch@freebsd.org Subject: Re: Which is the truth? (sycalls and traps) (fwd) In-Reply-To: <99Nov29.114712est.40340@border.alcanet.com.au> 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 Mon, 29 Nov 1999, Peter Jeremy wrote: > > Though in scheduling a long asleep thread, it's stack may > >be out on swap. You'd need to work out a way of 'pre-faulting' in the > >thread's context so that the scheduler didn't block trying to load it. > >or at least scheduling it in a way that allowed the fault to not be > >charged against the scheduler, but rather against the thread. > > > >The second may actually not be too hard. > > I'm not sure I follow: If a thread dereferences a pointer to a > non-resident page, how does the thread avoid blocking? You don't avoid teh fault, you just make sure that you are already officially "no longer the scheduler", but rather the thread you are waking up, then the kernel can know that it is safe to upcall to the scheduler again. remember, the original topic was "when the UTS get's a pagefault it blocks". In this case if it is no longer the UTS, then it's safe to ask the UTS to schedule something else while the page is being brought in. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 2:25:29 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 9D84C14C1F for ; Mon, 29 Nov 1999 02:25:26 -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 LAA14087 for ; Mon, 29 Nov 1999 11:25:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA62695 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 11:25:25 +0100 (MET) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 5EA2414C1F; Mon, 29 Nov 1999 02:24:32 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11sNyh-0006im-00; Mon, 29 Nov 1999 12:24:15 +0200 From: Sheldon Hearn To: "Daniel C. Sobral" Cc: jkh@freebsd.org, freebsd-arch@freebsd.org Subject: Re: rc.conf In-reply-to: Your message of "Sun, 28 Nov 1999 18:17:33 +0900." <199911280917.SAA00334@daniel.sobral> Date: Mon, 29 Nov 1999 12:24:15 +0200 Message-ID: <25839.943871055@axl.noc.iafrica.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 28 Nov 1999 18:17:33 +0900, "Daniel C. Sobral" wrote: > That's one thing, and it led me to consider another thing. Right now, > the logic for reading rc.conf files is inside /etc/defaults/rc.conf, [...] See PR 13724 for discussion that's already taken place. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 4:24:22 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 EA7BD14F0E for ; Mon, 29 Nov 1999 04:24:20 -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 NAA16449 for ; Mon, 29 Nov 1999 13:24:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA63224 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 13:24:19 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0A1D514F0E for ; Mon, 29 Nov 1999 04:24:13 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt60.pcnet.net [206.105.29.134]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA26932; Mon, 29 Nov 1999 07:24:12 -0500 (EST) Message-ID: <384270AE.D0250340@vigrid.com> Date: Mon, 29 Nov 1999 07:25:18 -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: Julian Elischer Cc: arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Yes, I understood them just fine :) I'm still not sold on the new > > syscall gate and IOCB, because I think we have to make at least one > > system call when threads are switched or resumed. > > > > I'm not completely sold on them either. > I just have a gut feeling on it based on doing this for 25 years. Well let's see if we can make them work, now that we know more of the issues. One potential problem I see with placing the IOCBs at a fixed location in the calling threads stack is that you then are tied to having to find TSD for every system call. I say TSD, but really mean you have to go through the same hoops as getting TSD. We don't know how fast this is going to be for i386. I think if we allocate the IOCB from the stack at the time of the system call, it will be faster. If the thread blocks, then kernel can provide enough information so that the UTS upcall can find the IOCB, set the IOCBptr in the current thread, mark the thread as blocked, etc. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 4:59:44 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 AB4F1154C1 for ; Mon, 29 Nov 1999 04:59: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 NAA17146 for ; Mon, 29 Nov 1999 13:59:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA63373 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 13:59:38 +0100 (MET) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5E46114E40; Mon, 29 Nov 1999 04:59:29 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA95132; Mon, 29 Nov 1999 13:59:05 +0100 (CET) (envelope-from des) To: Tony Landells Cc: hackers@freebsd.org Subject: Re: new IPFW References: <199911242152.IAA26077@tungsten.austclear.com.au> From: Dag-Erling Smorgrav Date: 29 Nov 1999 13:59:05 +0100 In-Reply-To: Tony Landells's message of "Thu, 25 Nov 1999 08:52:28 +1100" Message-ID: Lines: 36 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moving from -ipfw and -arch to -hackers] Tony Landells writes: > One concern I would have with that is that there are a lot of tools > built on BPF that I would prefer to not be able to run on the firewall. Don't confuse BPF with promiscuous mode. BPF is simply a programmable packet filter and does not in and of itself represent a security risk. Promiscuous mode allows a host to capture packets not destined to itself, and may represent a security risk on shared media networks (e.g. 10Base2, unswitched 10BaseT). The attached patch prevents switching into promiscuous mode when running in "Network secure mode" (securelevel 3 or higher). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no Index: if.c =================================================================== RCS file: /home/ncvs/src/sys/net/if.c,v retrieving revision 1.77 diff -u -r1.77 if.c --- if.c 1999/11/22 02:44:51 1.77 +++ if.c 1999/11/29 12:52:07 @@ -908,6 +908,8 @@ int error; if (pswitch) { + if (securelevel >= 3) + return (EPERM); /* * If the device is not configured up, we cannot put it in * promiscuous mode. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 6:41:52 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 9B86614D8D for ; Mon, 29 Nov 1999 06:41:48 -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 PAA19260 for ; Mon, 29 Nov 1999 15:41:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA63966 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 15:41:45 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 5453F14D8D for ; Mon, 29 Nov 1999 06:41:26 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C7E121CC6 for ; Mon, 29 Nov 1999 22:41:25 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: arch@freebsd.org Subject: Threads stuff - reality check.. Date: Mon, 29 Nov 1999 22:41:25 +0800 From: Peter Wemm Message-Id: <19991129144125.C7E121CC6@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd hate to ruin a good pie-in-the-sky session on the design of the killer threads system and all, but I kinda wonder if we're aiming too hight to start with? Wouldn't it be better to put the pieces that we already have together and make something in time for 4.0 that runs with better concurrency than we have now? ie: perhaps based on Richard's native linuxthreads port? Most of the pieces are there, but it needs work to tidy up the loose ends and bring it up to date, and probably some debugging to get it to work properly. There isn't a chance in hell that the Ultimate Threads are going to be ready for 4.0, but we have got a pretty good shot at doing an intermediate version that's at least comparable to what Linux does. Things like squid etc really hurt without threads with blocking support, and it will be a damn shame to miss the opportunity to have an alternative to uthreads in 4.0. Most of the work is already done after all. It doesn't take much to get the kit from http://lt.tar.com/ to compile and pretty much work. Many of the primatives and infrastructure would be *directly* applicable to the new threads - eg: reentrancy support in libc etc. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 7:18:14 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 492E0150E0 for ; Mon, 29 Nov 1999 07:18:11 -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 QAA20025 for ; Mon, 29 Nov 1999 16:18:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA64186 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 16:18:07 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2483B15033 for ; Mon, 29 Nov 1999 07:18:01 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id HAA05245; Mon, 29 Nov 1999 07:17:43 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 07:17:43 -0800 (PST) From: Matthew Dillon Message-Id: <199911291517.HAA05245@apollo.backplane.com> To: Peter Wemm Cc: arch@freebsd.org Subject: Re: Threads stuff - reality check.. References: <19991129144125.C7E121CC6@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I'd hate to ruin a good pie-in-the-sky session on the design of the killer :threads system and all, but I kinda wonder if we're aiming too hight to start :with? : :Wouldn't it be better to put the pieces that we already have together and :make something in time for 4.0 that runs with better concurrency than we :have now? ie: perhaps based on Richard's native linuxthreads port? : :Most of the pieces are there, but it needs work to tidy up the loose ends :and bring it up to date, and probably some debugging to get it to work :properly. There isn't a chance in hell that the Ultimate Threads are going :to be ready for 4.0, but we have got a pretty good shot at doing an :intermediate version that's at least comparable to what Linux does. Things :like squid etc really hurt without threads with blocking support, and it :will be a damn shame to miss the opportunity to have an alternative to :uthreads in 4.0. Most of the work is already done after all. It doesn't :take much to get the kit from http://lt.tar.com/ to compile and :pretty much work. : :Many of the primatives and infrastructure would be *directly* applicable to the :new threads - eg: reentrancy support in libc etc. : :Cheers, :-Peter Heh heh. Good point. Doing this would also give us an infrastructure to test against as changes are made. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 7:39: 5 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 9CE1A151A0 for ; Mon, 29 Nov 1999 07:38:59 -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 QAA20317 for ; Mon, 29 Nov 1999 16:38:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA64285 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 16:38:58 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 245DD15249 for ; Mon, 29 Nov 1999 07:34:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id HAA05346; Mon, 29 Nov 1999 07:34:24 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 07:34:24 -0800 (PST) From: Matthew Dillon Message-Id: <199911291534.HAA05346@apollo.backplane.com> To: Julian Elischer Cc: "Daniel M. Eischen" , arch@freebsd.org Subject: Re: Threads stuff References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Here is where you and I part company to some extent. : :A process must be limitted in CPU resources to teh same anount whether it :be unthreaded, or threaded. If you want yuor 20 threads to be scheduled :at teh same weighting as teh other processes then a process with 20 :threads will have 20 times the scheduling clout as one with 1. I believe I covered that point, but I will restate it in clearer terms. You can do this simply by tracking the quantum in the proc structure. It does not prevent you from using the KSE as the scheduling entity. It does not change the complexity at all, in fact. :This is crucial to being able to get the behaviour expected by the :threading standards. If you want a bigger slice of the cake you need to :abide by the same rules a s anormal process.. :i.e. fork (rfork) and spread your work over two sets of quanta. Which is not desireable. You create a situation whereby the cpu resource is now being used non-deterministically based on the scheduling class within the multi-threaded application AND also based on other factors including the number of physical cpus in the system. Also, in order to simulate N virtual cpus you wind up needing N rfork()'d processes. In my scheme you can simulate N virtual cpus without taking up *any* significant kernel resources - not even extra KSE's (see below). :It's not a 'big mistake'. I think it's almost a requirement. Again, there is a big difference between the scheduling quantum and using the KSE as the scheduling entity. The two do not have to go together. It does not add complexity to keep them separate. Not at all. I can outline the code involved if you are not convinced. I've implemented two schedulers recently that use this concept. :> the kernel (once the MP lock becomes fine grained), and we should not have :> to rfork() to get it. : :You are forgetting that you must ASK for parallelism otherwise you are :limitted to one process-worth of quanta. A process is limitted to one :CPU-second per second. To allow you to automatically get more is unfaair :on the other processes. You need to go through the same limits as they :do, though we make it almos infinitly easier for you to do so. In your scheme you must ask for parallelism. In mine you don't. Or, in other terms: In your scheme you must specify the exact amount of parallelism you want whereas in mine you can simply specify that you want parallelism and do not necessarily have to specify how much, nor is the level of system resource use dependant on the amount of (virtual) parallelism you want. : :> There is absolutely no reason why KSE's associated with the same process :> cannot be run in parallel, which means that you might as well use KSE's :> as your scheduling entity rather then processes. : :Except that that's not a goal. You are limitted to the virtual processors :(your words) that you have. That's not a goal for you. It is a goal for me for many reasons, the most important one being that by using KSE's in this matter you can collapse four different scheduling problems into a single algorithm. (kernel threads, kernel interrupt threads, standard processes, user threads). :> By attempting to use a process as your scheduling entity you create a :> very complex scheduling situation whereby the kernel threads require :> completely different code to support then the user threads. I'd rather :> have the same code control both - it's easier in concept, design, and :> implementation. : :no I disagree about the complexity.. :if you wish to add the required contrraints directly upon KSEs and :then make the m behave correctly With respect to other processes.. :(i.e. limit themselves to their quanta) you will add back almost all of :that complexity, except now you have written it as separate code. This is absolutely NOT true. Not in the least. Having the quanta in the process structure adds no significant complexity over having it in the KSE. The only thing that happens is that kse->quantum_counter would become kse->parent_proc->quantum_counter. Not a big deal. You do not even need to worry about locking the field because the small simultanious write window is not statistically relevant. :> you can use the *same* KSE for the next running thread on that cpu. The :> result is massive L1/L2 cache sharing for the kernel stack to the point :> where you don't even need a kernel stack pre-assigned for your long-idle :> processes in some cases (restartable system call case). : :You dont assign a floating KSE to each processor, you assign one to each :virtual processor, and guess what that is? :Everything you say above is still true for that case. Especially if there :is processor affinity for (sub)processes. No, you do NOT have to assign a floating KSE to each virtual processor, at least not in my scheme. There are only two situations where a KSE must be assigned: * When a KSE is currently *running* on a physical cpu (not a virtual cpu). * When a KSE is blocked in the kernel When a thread is runnable but not blocked in the kernel and *NOT* currently assigned to a physical cpu by the kernel, it does NOT need to have a KSE assigned to it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 8:12: 9 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 70FE214CAE for ; Mon, 29 Nov 1999 08:12:06 -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 RAA20719 for ; Mon, 29 Nov 1999 17:12:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64476 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:11:45 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 028E21501D for ; Mon, 29 Nov 1999 08:11:22 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA09041; Mon, 29 Nov 1999 09:11:18 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA19058; Mon, 29 Nov 1999 09:11:13 -0700 Date: Mon, 29 Nov 1999 09:11:13 -0700 Message-Id: <199911291611.JAA19058@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: References: <19991124220406.X301@sturm.canonware.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This sounds similar to Solaris LWPs in that there are potentially KSEs > > blocked in the kernel, whereas with scheduler activations (SA), that > > doesn't happen under normal circumstances. > > No, under SA KSE's block. and another KSE is generated to act as a > replacement. it is used to run the activation that is passed to the > scheduler, and this the next thread the process runs. That's not how I read the paper. I think we all might be on the 'same page', but I think we're all using different terminology. How's about we define what a KSE is, a SA is, and come up with some other term for a userland 'thread'? It seems that Julian is using the same term for a userland thread and a context that can go into the userland as a KSE, but I'm not sure. Assuming for a moment that this is the case, then is a SA a 'kernel context' that wraps up a KSE when it goes 'live' (the UTS schedules it)? If so, then the KSE and the SA are essentially the same thing, aren't they? > there must be. > there is a stack that must be saved, and registers. this is a KSE. > > > The syscall context has some kernel context, but there is no bonifide > > context, such as with Solaris's LWP model. When the syscall completes, a > > new activation is created for the upcall to the UTS. > > A KSE is basicaly saved proocessor state, including a stack, and some > linkage points to allow that to be hug of various other structures, e.g. > sleep queues, procs , subprocs, etc. How does the UTS allow another thread to use this 'KSE' when *IT* decides to allow another user0land thread to run? As I read the SA paper, this is how things are done. > > That said, I disagree with the idea of the UTS having explicit control over > > scheduling of KSEs. Hmm.... I think that there should be exactly one KSE per > > processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and > > that threads should be multiplexed onto the KSEs. This lets the kernel > > schedule KSEs as it sees fit, and lets the UTS divide the runtime of the > > KSEs as it sees fit. How does the UTS 'divide' the runtime if it isn't allowed to schedule the KSE? What is the difference between 'schedule' and 'divide'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 8:22:32 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 47847150FC for ; Mon, 29 Nov 1999 08:22:28 -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 RAA20838 for ; Mon, 29 Nov 1999 17:22:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64551 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:22:26 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D657A151A2 for ; Mon, 29 Nov 1999 08:21:33 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA06301; Mon, 29 Nov 1999 08:21:30 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 08:21:30 -0800 (PST) From: Matthew Dillon Message-Id: <199911291621.IAA06301@apollo.backplane.com> To: Nate Williams Cc: Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > blocked in the kernel, whereas with scheduler activations (SA), that :> > doesn't happen under normal circumstances. :> :> No, under SA KSE's block. and another KSE is generated to act as a :> replacement. it is used to run the activation that is passed to the :> scheduler, and this the next thread the process runs. : :That's not how I read the paper. I think we all might be on the 'same :page', but I think we're all using different terminology. : :How's about we define what a KSE is, a SA is, and come up with some :other term for a userland 'thread'? : :It seems that Julian is using the same term for a userland thread and a :context that can go into the userland as a KSE, but I'm not sure. : :Assuming for a moment that this is the case, then is a SA a 'kernel The terminology I have been using, which I thought was the same as Julian's but may not be, is: Thread Two entities. A kernel structure 'Thread' and also a similarly named but independant user structure within the UTS. KSE A kernel scheduleable entity. I was using this to mean the contextual information (such as a kernel stack) required for the kernel to be able to run a thread. Not required for runnability, only required to actually run the thread and also held over of the thread blocks while in the kernel. Process Our good old process. I think I actually misspoke earlier. Runnability in the kernel scheduler is governed by 'Thread', not 'KSE' with my idea. Only currently running contexts require a KSE. i.e. you might have 10 runnable Threads linked into the kernel's scheduler but if you have a two-cpu system, only 2 of those 10 will actually be running at any given moment and require KSE's. With my system we change the kernel scheduling entity from a 'Process' to a 'Thread' and a Thread can then optionally (dynamically) be assigned a KSE as required to actually run. The KSE is a kernel abstraction and essentially *invisible* to user mode. The Thread is a kernel abstraction that is visible to user mode. With Julian's idea the kernel scheduling entity remains a 'Process', KSE's are special cases within that process, and Threads appear to be entirely userland entities. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 8:29:44 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 C704B15300 for ; Mon, 29 Nov 1999 08:29: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 RAA20932 for ; Mon, 29 Nov 1999 17:29:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64598 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:29:40 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 80A7F15300 for ; Mon, 29 Nov 1999 08:29:31 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA09194; Mon, 29 Nov 1999 09:29:26 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA19154; Mon, 29 Nov 1999 09:29:24 -0700 Date: Mon, 29 Nov 1999 09:29:24 -0700 Message-Id: <199911291629.JAA19154@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911291621.IAA06301@apollo.backplane.com> References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :How's about we define what a KSE is, a SA is, and come up with some > :other term for a userland 'thread'? > : > :It seems that Julian is using the same term for a userland thread and a > :context that can go into the userland as a KSE, but I'm not sure. > : > :Assuming for a moment that this is the case, then is a SA a 'kernel > > The terminology I have been using, which I thought was the same as > Julian's but may not be, is: > > Thread > > Two entities. A kernel structure 'Thread' and also a similarly > named but independant user structure within the UTS. So far so good. However, we need to differentiate between a 'Userland' thread, and a 'kernel thread' somehow. Also, how does a Userland thread 'become' a Kernel thread? (We need a hybrid of Userland/Kernel threads in order for this to be a viable/effecient solution.) > KSE > > A kernel scheduleable entity. I was using this to mean the > contextual information (such as a kernel stack) required for > the kernel to be able to run a thread. Not required for > runnability, only required to actually run the thread and > also held over of the thread blocks while in the kernel. ^^ if? Can you expound on this more? Is this transferrable to another 'thread' in the kernel? If so, what is left? If not, what is the 'thing' that we are transferring across? > Process > > Our good old process. I think this is probably the *only* thing we all agree upon the definition of. :) > I think I actually misspoke earlier. Runnability in the kernel scheduler > is governed by 'Thread', not 'KSE' with my idea. Only currently running > contexts require a KSE. i.e. you might have 10 runnable Threads linked > into the kernel's scheduler but if you have a two-cpu system, only 2 of > those 10 will actually be running at any given moment and require KSE's. So far so good. > With my system we change the kernel scheduling entity from a 'Process' > to a 'Thread' and a Thread can then optionally (dynamically) be assigned > a KSE as required to actually run. I think the term you are using for 'Thread' would be an SA, but I'm not sure everyone else would agree. > The KSE is a kernel abstraction and > essentially *invisible* to user mode. The Thread is a kernel abstraction > that is visible to user mode. I see KSE as being 'kernel context', and that *everytime* a 'thread' (userland) makes a system call, it gets assigned (created, whatever) a KSE. However, in order to do proper thread priorities, who determines which threads get a 'SA' in this context? There could be lots of threads vying for a SA (or kernel 'Thread') in this context, and the only entity with enough context to decide correctly is the UTS. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 9: 6:31 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 6D41614A0D for ; Mon, 29 Nov 1999 09:06:26 -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 SAA21380 for ; Mon, 29 Nov 1999 18:06:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA64702 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 18:06:25 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D393314C28 for ; Mon, 29 Nov 1999 09:05:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA06592; Mon, 29 Nov 1999 09:05:55 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 09:05:55 -0800 (PST) From: Matthew Dillon Message-Id: <199911291705.JAA06592@apollo.backplane.com> To: Nate Williams , Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> <199911291629.JAA19154@mt.sri.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The terminology I have been using, which I thought was the same as :> Julian's but may not be, is: :> :> Thread :> :> Two entities. A kernel structure 'Thread' and also a similarly :> named but independant user structure within the UTS. : :So far so good. However, we need to differentiate between a 'Userland' :thread, and a 'kernel thread' somehow. Also, how does a Userland thread :'become' a Kernel thread? (We need a hybrid of Userland/Kernel threads :in order for this to be a viable/effecient solution.) In my scheme the kernel controls the ultimate scheduling of threads so 'Thread' is a kernel thread. The UTS may implement its own thread structure for userland in order to tie the kernel Thread into the userland libraries, but there would have to be a 1:1 correspondance (since userland needs to make a system call to schedule runnability of a thread). The idea here is that the kernel Thread structure is very small, holding only the userland %esp, a reference to the governing struct proc, and a reference to the KSE (which need only be present in certain situations, see below). The kernel will store the userland register state on the userland stack instead of in the Thread structure, keeping the Thread structure *very* small. If we take a stack fault and no memory is available to allocate a new page, the situation is simply treated the same as any other time the kernel blocks while in the supervisor (see below). No special case or extra code is required at all, really. Since the case only occurs under extreme conditions we don't have to worry about it except to ensure that we do not enter a low-memory deadlock when the case occurs. It is precisely the ability to block in supervisor mode that prevents the low memory deadlock from occuring. :> KSE :> :> A kernel scheduleable entity. I was using this to mean the :> contextual information (such as a kernel stack) required for :> the kernel to be able to run a thread. Not required for :> runnability, only required to actually run the thread and :> also held over of the thread blocks while in the kernel. : ^^ :if? Can you expound on this more? Is this transferrable to another :'thread' in the kernel? If so, what is left? If not, what is the :'thing' that we are transferring across? Yes, the KSE is transferable. There are two situations in my scheme where a KSE is required: * The thread is currently running on a physical cpu (not just runnable, but actually *running* ... just like you might have dozens of processes in a 'R'un state (runnable) but on a UP system only one can actually be *running* at a time. * The thread has gone to sleep while in the kernel. i.e. the thread has blocked while in the kernel. Taking them one at a time: (1) The thread is currently running - a KSE is required in case the thread wishes to make a system call, an interrupt occurs, or a fault occurs. The thread is not actually *using* the KSE except for those occurances so if the thread is switched out without the above occuring, the KSE can be reused for the next runnable thread that is switched in by the kernel scheduler. We CANNOT allocate a KSE for a thread upon entering the supervisor without getting into potential deadlock situations, thus the KSE must already exist so entry into the supervisor can occur without having to allocate memory. (2) The thread blocks while in the kernel. For example, the thread makes a synchronous system call such as a read() which blocks. The thread utilizes the KSE that was previously idle and now blocks. The kernel cannot migrate that KSE to another thread because it is needed to hold state for the current thread. Another example, the kernel decides to switch away from a thread currently running in usermode (not a system call, or a special synchronous give-up-the-cpu call) The kernel will attempt to save the register & FP state onto the thread's own user stack. If this succeeds the kernel can switch away from the thread and reuse the KSE for the next thread (assuming it doesn't already have one). On the otherhand, if the act of saving the registers onto the userstack blocks due to a fault and a low-memory condition, swap-in, or other state, the kernel is forced to use the existing KSE to block in the supervisor and saves the register state there (just like normal). When memory becomes available the kernel can complete the switchout for the userstack and destroy the KSE. As you might have gathered, in the case where the thread being switched in by the kernel has no KSE, the kernel simply resumes the user thread with an iret. The previous state that was pushed onto the user thread's stack is restored by a restore vector that was also pushed onto the user thread's stack. The kernel can use the per-cpu supervisor stack to temporarily hold the interrupt return stack to properly restore the user ring. This may sound complex, but it is very close to what our kernel already does currently and would not require significant programming to implement. It would allow us to reduce the kernel memory footprint required to manage threads to a size that is so small that we could scale to hundreds of thousands of threads if we needed to. :> Process :> :> Our good old process. : :I think this is probably the *only* thing we all agree upon the :definition of. :) Kinda hard to screw this one up, yup! :... :> into the kernel's scheduler but if you have a two-cpu system, only 2 of :> those 10 will actually be running at any given moment and require KSE's. : :So far so good. : :> With my system we change the kernel scheduling entity from a 'Process' :> to a 'Thread' and a Thread can then optionally (dynamically) be assigned :> a KSE as required to actually run. : :I think the term you are using for 'Thread' would be an SA, but I'm not :sure everyone else would agree. : :> The KSE is a kernel abstraction and :> essentially *invisible* to user mode. The Thread is a kernel abstraction :> that is visible to user mode. : :I see KSE as being 'kernel context', and that *everytime* a 'thread' :(userland) makes a system call, it gets assigned (created, whatever) a :KSE. However, in order to do proper thread priorities, who determines :which threads get a 'SA' in this context? There could be lots of :threads vying for a SA (or kernel 'Thread') in this context, and the :only entity with enough context to decide correctly is the UTS. : :Nate I see a KSE as being a 'kernel context' as well. The only difference between your description and mine is that the threads currently running on a cpu (not runnable, just running) requires a KSE to be assigned to it so the kernel context is available to switch into when the system call is made. The KSE *cannot* be allocate after the fact without getting into low-memory deadlock situations. A runnable thread (or a stopped thread) which has *no* kernel context does not need a KSE while not being run by a cpu. Thread priorities are controlled by the UTS. The UTS schedules and deschedules kernel Threads. For example, if you have 10 user mode threads which are all runnable, and the UTS is implementing a serialized FIFO scheduling class, the UTS simply schedules one of those threads at a time with the kernel. If the UTS wants to run all of them simultaniously, the UTS schedules all of the threads with the kernel. The kernel's 'run' and 'runnability' state for a thread is entirely separate from the UTS's 'run' and 'runnability' state. This difference is how the UTS imposes the scheduling class on the thread. The kernel aggregates the cpu use for all running kernel threads simply by having the cpu use counter be in the governing process structure. In otherwords, you could have 50 threads running in the kernel associated with a single process but they will only get the same aggregate cpu as that single process would get. This is trivial to do - essentially two lines of code. The purpose of this is not to impose a scheduling class on the threads, that is what the UTS does when the UTS schedules and deschedules the threads with the kernel. The purpose is to place all threads related to an umbrella under the scheduling class and priority of the governing process. Did I explain that well enough? I know its confusing. We are talking about two totally unassociated pieces of the scheduling puzzle here. The kernel only deals with the piece that governs cpu resource sharing between processes (even though the scheduling entity is a 'Thread'), the UTS deals with the scheduling of threads within the slice of cpu(es) (not the plural) the kernel gives the process. The UTS does not have to know how many real cpu's exist in the system. It simulates N virtual cpu's simply by scheduling N threads with the kernel at any given moment. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 9:19:57 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 12A5414CB4 for ; Mon, 29 Nov 1999 09:19: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 SAA21540 for ; Mon, 29 Nov 1999 18:19:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA64769 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 18:19:48 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4076514CB4 for ; Mon, 29 Nov 1999 09:19:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA06713; Mon, 29 Nov 1999 09:19:39 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 09:19:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911291719.JAA06713@apollo.backplane.com> To: Nate Williams , Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> <199911291629.JAA19154@mt.sri.com> <199911291705.JAA06592@apollo.backplane.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : As you might have gathered, in the case where the thread being : switched in by the kernel has no KSE, the kernel simply resumes : the user thread with an iret. The previous state that was pushed : onto the user thread's stack is restored by a restore vector that : was also pushed onto the user thread's stack. The kernel can use : the per-cpu supervisor stack to temporarily hold the interrupt return : stack to properly restore the user ring. Let me amend this. I got this wrong. The kernel will have a KSE available to it when switching in a thread that has no KSE of its own. This KSE will either be transfered from the previous thread, or allocated. What I was trying to say here was that this KSE is 'idle' in regards to resuming the thread, because all the register state and restore vector is on the user stack and can be restored after we return to user mode. There is no per-cpu supervisor stack per-say, the supervisor stack the kernel uses is the one provided by the KSE. In the case where the kernel is resuming a thread that was in userland, the kernel simply pushes the interrupt restoration vector and ring change as appropriate onto the stack provided by the KSE and issues an IRET, or RETI, or whatever the instruction is. The instruction pops the information (the KSE is thus idle again) and resumes the usermode thread and the restore vector pushed onto the usermode thread. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 9:34: 9 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 BA64014FB9 for ; Mon, 29 Nov 1999 09:34:00 -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 SAA21759 for ; Mon, 29 Nov 1999 18:33:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA64837 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 18:33:54 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 5027614FB9 for ; Mon, 29 Nov 1999 09:33:46 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA05359; Mon, 29 Nov 1999 12:27:05 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA92350; Mon, 29 Nov 1999 12:29:19 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3842B7EE.F0D02992@vigrid.com> Date: Mon, 29 Nov 1999 12:29:18 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@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: > The terminology I have been using, which I thought was the same as > Julian's but may not be, is: > > Thread > > Two entities. A kernel structure 'Thread' and also a similarly > named but independant user structure within the UTS. Under the current Julian/Dan proposal, there need not be a kernel structure 'Thread'. The UTS just sees cooperating subprocesses (rforks). I think this is because it's currently very easy to implement without drastically changing kernel internals. > > KSE > > A kernel scheduleable entity. I was using this to mean the > contextual information (such as a kernel stack) required for > the kernel to be able to run a thread. Not required for > runnability, only required to actually run the thread and > also held over of the thread blocks while in the kernel. > > Process > > Our good old process. > > I think I actually misspoke earlier. Runnability in the kernel scheduler > is governed by 'Thread', not 'KSE' with my idea. Only currently running > contexts require a KSE. i.e. you might have 10 runnable Threads linked > into the kernel's scheduler but if you have a two-cpu system, only 2 of > those 10 will actually be running at any given moment and require KSE's. > > With my system we change the kernel scheduling entity from a 'Process' > to a 'Thread' and a Thread can then optionally (dynamically) be assigned > a KSE as required to actually run. The KSE is a kernel abstraction and > essentially *invisible* to user mode. The Thread is a kernel abstraction > that is visible to user mode. > > With Julian's idea the kernel scheduling entity remains a 'Process', > KSE's are special cases within that process, and Threads appear to > be entirely userland entities. Personally, I'd like to see kernel threads be the scheduling entity, not processes. In this scheme, what Julian and I have called subprocesses would be called kernel threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 10:20:44 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 36759150B6 for ; Mon, 29 Nov 1999 10:20:39 -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 TAA22262 for ; Mon, 29 Nov 1999 19:20:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA65240 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 19:20:37 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id A02E314D96 for ; Mon, 29 Nov 1999 10:20:17 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA10243; Mon, 29 Nov 1999 11:20:16 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA19768; Mon, 29 Nov 1999 11:20:15 -0700 Date: Mon, 29 Nov 1999 11:20:15 -0700 Message-Id: <199911291820.LAA19768@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Wemm Cc: arch@freebsd.org Subject: Re: Threads stuff - reality check.. In-Reply-To: <19991129144125.C7E121CC6@overcee.netplex.com.au> References: <19991129144125.C7E121CC6@overcee.netplex.com.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd hate to ruin a good pie-in-the-sky session on the design of the killer > threads system and all, but I kinda wonder if we're aiming too hight to start > with? > > Wouldn't it be better to put the pieces that we already have together and > make something in time for 4.0 that runs with better concurrency than we > have now? ie: perhaps based on Richard's native linuxthreads port? Last I heard, this work was 'unacceptable' to be added to FreeBSD, similar to the old 'shared library' implementation work. Unless we had a N:M threading model, there was a general consensus from 'those in positions of authority' that we shouldn't be using the 'simple' method at all. I can go dig up the reference if desired. I agree with you that a 'poor' solution would be better than no solution. (However, the poor solution appears to work pretty darn good given Richard's recent postings on the benchmarks he's seeing...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 10:30:24 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 DC36E14A27 for ; Mon, 29 Nov 1999 10:30:21 -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 TAA22370 for ; Mon, 29 Nov 1999 19:30:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA65295 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 19:30:17 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3C1E9152F4 for ; Mon, 29 Nov 1999 10:29:33 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA10335; Mon, 29 Nov 1999 11:29:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA19811; Mon, 29 Nov 1999 11:29:27 -0700 Date: Mon, 29 Nov 1999 11:29:27 -0700 Message-Id: <199911291829.LAA19811@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911291705.JAA06592@apollo.backplane.com> References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> <199911291621.IAA06301@apollo.backplane.com> <199911291629.JAA19154@mt.sri.com> <199911291705.JAA06592@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Threading definitions and such ] While I'm enjoying the conversation, and I believe there's more to talk about, I'm going to withdraw from the discussion simply because I don't want to fragment the discussion too much. There is a *LOT* of other conversations happening on this topic, and rather than try and keep that many balls in the air, I'd like to focus in on what everyone else is talking about. Plus it appears that the other discussions are starting to converge and deal with these issues as well. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 11:16:40 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 E152314D4A for ; Mon, 29 Nov 1999 11:16:38 -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 UAA22829 for ; Mon, 29 Nov 1999 20:16:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA65572 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 20:16:36 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id DD4A714D4A for ; Mon, 29 Nov 1999 11:16:13 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id UAA10019 for arch@freebsd.org; Mon, 29 Nov 1999 20:16:11 +0100 (CET) Date: Mon, 29 Nov 1999 20:16:11 +0100 From: Martin Cracauer To: arch@freebsd.org Subject: What to do about "subscript has type `char'" warnings? Message-ID: <19991129201610.A9998@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Newest compiler now produces a lot of "subscript has type `char'" warnings for sh (its syntax table). I would change direct appearences of char bla; string[bla]; to int bla; string[bla]; which IMHO is consistent with ANSI C and its int and char properties. A different matter is an index that is a followed pointer to a char; char *s = syntax[2]; string[*s]; I could either a) use an additional int variable, which causes some overhead, of course b) or cast char *s = syntax[2]; string[(int)*s]; I tend to cast for the second case, although it's a little inconsistent with the fix for the direct case. Opinions? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 11:26:52 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 A8C7215575 for ; Mon, 29 Nov 1999 11:26:48 -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 UAA22921 for ; Mon, 29 Nov 1999 20:26:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA65631 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 20:26:48 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id AB89815706 for ; Mon, 29 Nov 1999 11:23:57 -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 LAA48683; Mon, 29 Nov 1999 11:23:50 -0800 (PST) Date: Mon, 29 Nov 1999 11:23:49 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: Matthew Dillon , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911291829.LAA19811@mt.sri.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 where is the other discussion going on? On Mon, 29 Nov 1999, Nate Williams wrote: > [ Threading definitions and such ] > > While I'm enjoying the conversation, and I believe there's more to talk > about, I'm going to withdraw from the discussion simply because I don't > want to fragment the discussion too much. > > There is a *LOT* of other conversations happening on this topic, and > rather than try and keep that many balls in the air, I'd like to focus > in on what everyone else is talking about. > > Plus it appears that the other discussions are starting to converge and > deal with these issues as well. > > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 11:31:24 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 078551529C for ; Mon, 29 Nov 1999 11:31:18 -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 UAA22979 for ; Mon, 29 Nov 1999 20:31:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA65673 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 20:31:14 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A47291529C for ; Mon, 29 Nov 1999 11:30:52 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA08250; Mon, 29 Nov 1999 11:30:46 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 11:30:46 -0800 (PST) From: Matthew Dillon Message-Id: <199911291930.LAA08250@apollo.backplane.com> To: Martin Cracauer Cc: arch@freebsd.org Subject: Re: What to do about "subscript has type `char'" warnings? References: <19991129201610.A9998@cons.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Newest compiler now produces a lot of "subscript has type `char'" :warnings for sh (its syntax table). : :I would change direct appearences of : char bla; : string[bla]; :to : int bla; : string[bla]; :which IMHO is consistent with ANSI C and its int and char properties. : :A different matter is an index that is a followed pointer to a char; : char *s = syntax[2]; : string[*s]; : :I could either :a) use an additional int variable, which causes some : overhead, of course :b) or cast : char *s = syntax[2]; : string[(int)*s]; : :I tend to cast for the second case, although it's a little :inconsistent with the fix for the direct case. Opinions? : :Martin :-- :%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% :Martin Cracauer http://www.cons.org/cracauer/ : Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 This warning exists because many programmers do not realize that the signess of 'char' is platform dependant. 'char' defaults to being signed on x86 and unsigned on MIPS, for example. People often make the mistake of trying to index an array with 'char'. The correct solution is to cast it properly. If casting a char to an int is not correct due to a possible signed result, then you need to cast the char to an unsigned char first. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 11:33:38 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 9AFB914F37 for ; Mon, 29 Nov 1999 11:33:36 -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 UAA23000 for ; Mon, 29 Nov 1999 20:33:35 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA65695 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 20:33:35 +0100 (MET) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 52D4815376 for ; Mon, 29 Nov 1999 11:33:29 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id DF2471C4D; Mon, 29 Nov 1999 13:34:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id D138C3836; Mon, 29 Nov 1999 13:34:34 -0500 (EST) Date: Mon, 29 Nov 1999 13:34:34 -0500 (EST) From: Bill Fumerola To: Matthew Dillon Cc: Martin Cracauer , arch@freebsd.org Subject: Re: What to do about "subscript has type `char'" warnings? In-Reply-To: <199911291930.LAA08250@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 Mon, 29 Nov 1999, Matthew Dillon wrote: > :b) or cast > : char *s = syntax[2]; > : string[(int)*s]; I would suggest using this option and I will be using this in some of my -Wall fixes I have in the pipeline. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 11:38:10 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 20FD114D50 for ; Mon, 29 Nov 1999 11:38:07 -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 UAA23049 for ; Mon, 29 Nov 1999 20:38:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA65748 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 20:38:06 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 84B3A14D50 for ; Mon, 29 Nov 1999 11:37:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA08363; Mon, 29 Nov 1999 11:37:56 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 11:37:56 -0800 (PST) From: Matthew Dillon Message-Id: <199911291937.LAA08363@apollo.backplane.com> To: Bill Fumerola Cc: Martin Cracauer , arch@freebsd.org Subject: Re: What to do about "subscript has type `char'" warnings? References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Mon, 29 Nov 1999, Matthew Dillon wrote: : :> :b) or cast :> : char *s = syntax[2]; :> : string[(int)*s]; : :I would suggest using this option and I will be using this in some :of my -Wall fixes I have in the pipeline. : :-- :- bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - That useage is not portable unless you can guarentee that the characters in the specified string range only from 0-127. These useages would be portable: string[(unsigned char)*s]; string[(int)(unsigned char)*s]; string[(int)(signed char)*s]; -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 12:11: 5 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 0B00515184 for ; Mon, 29 Nov 1999 12:11:03 -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 VAA23449 for ; Mon, 29 Nov 1999 21:11:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA65880 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 21:10:59 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2323A15184 for ; Mon, 29 Nov 1999 12:10:53 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p28-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.125]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id FAA21397 for ; Tue, 30 Nov 1999 05:10:52 +0900 (JST) Message-ID: <3842DBB5.8AFC9B6@newsguy.com> Date: Tue, 30 Nov 1999 05:01:57 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Threads and the scheduler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a question. Our scheduler is based on the assumption that i/o bound processes will block, and cpu bound processes will not. Because of that, we can support a _lot_ of i/o bound processes on a 64 Hz scheduler. If, though, we allow the i/o bound processes to always make use of their full quanta through use of threads, won't this have a huge impact on our ability to support many i/o bound processes? So, I guess what I'm getting at is: won't the proposed thread model have an impact on the effectiveness of our scheduler? -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 12:19:34 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 F1B2914E03 for ; Mon, 29 Nov 1999 12:19:32 -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 VAA23508 for ; Mon, 29 Nov 1999 21:19:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA65906 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 21:19:25 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A38B214E03 for ; Mon, 29 Nov 1999 12:19:14 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Tue, 30 Nov 1999 07:11:53 +1100 Content-return: prohibited Date: Tue, 30 Nov 1999 07:19:09 +1100 From: Peter Jeremy Subject: Re: Threads stuff - reality check.. In-reply-to: <19991129144125.C7E121CC6@overcee.netplex.com.au> To: Peter Wemm Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov30.071153est.40325@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991129144125.C7E121CC6@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-30 01:41:25 +1100, Peter Wemm wrote: >I'd hate to ruin a good pie-in-the-sky session on the design of the >killer threads system and all, but I kinda wonder if we're aiming too >hight to start with? Maybe... >Wouldn't it be better to put the pieces that we already have together and >make something in time for 4.0 that runs with better concurrency than we >have now? I _would_ like to see something make it into 4.0. I would also like to be reasonably sure that whatever we initially put into 4.0 can evolve into the final design as visualised by Julian, Daniel et al. As I understand it, this means that we need to have an `interim' threads implementation that has pretty much the same user API and kernel interface as our target (since the interfaces can't change until 5.0). I believe we're allowed to undertake a major re-work of the underlying code as long as the interfaces don't change. That suggests that our priorities need to be: 1) What user API do we want? I think there is general concensus that we need to use the same API as "everyone else" (pthread aka IEEE POSIX 1003.1c-1995). 2) What kernel interface do we need? This is still the subject of much discussion. In particular, it's not clear whether the thread scheduler should be in the kernel, userland or split between them in some manner. If we can agree on a suitably extensible kernel interface (which basically means that the copyin and copyout structures both begin with a version and size), we might be able to sneak through a substantial interface change without objections. 3) Do we have some interim code that can meet 1 and 2 and be committed before the feature freeze? Peter suggested Richard's native linuxthreads port. I can't somment on it's suitability. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 12:22: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 59587150D6 for ; Mon, 29 Nov 1999 12:22:44 -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 VAA23538 for ; Mon, 29 Nov 1999 21:22:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA65944 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 21:22:43 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3AC65152E8 for ; Mon, 29 Nov 1999 12:22:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA08694; Mon, 29 Nov 1999 12:22:35 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 12:22:35 -0800 (PST) From: Matthew Dillon Message-Id: <199911292022.MAA08694@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have a question. : :Our scheduler is based on the assumption that i/o bound processes :will block, and cpu bound processes will not. Because of that, we :can support a _lot_ of i/o bound processes on a 64 Hz scheduler. If, :though, we allow the i/o bound processes to always make use of their :full quanta through use of threads, won't this have a huge impact on :our ability to support many i/o bound processes? : :So, I guess what I'm getting at is: won't the proposed thread model :have an impact on the effectiveness of our scheduler? : :-- :Daniel C. Sobral (8-DCS) No, it won't, because most context switches are synchronous and the tick interval doesn't apply in those cases. Asynchronizing I/O does not necessarily mean that the calling thread will continue to run. If it has nothing to do it is going to exit or go to sleep whether the I/O is asynchronous or not. It is definitely not going to waste cpu finishing out its quanta. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 13:27:55 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 549EE14F2E for ; Mon, 29 Nov 1999 13:27: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 WAA24147 for ; Mon, 29 Nov 1999 22:27:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA66274 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 22:27:51 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id BEAE814C1F; Mon, 29 Nov 1999 13:27:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ABB3C1CD473; Mon, 29 Nov 1999 13:27:42 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 13:27:42 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <199911292104.NAA09106@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 Mon, 29 Nov 1999, Matthew Dillon wrote: > Hi Dan. Is it possible that we could adjust this feature to be enabled > with a config option? It seems to add a considerable amount of bulk to > the kernel that's deadweight for the people not using it. This raises some larger architectural issues which probably should be dealt with. Namely: * Changes which tighten security are arguably only useful if they're on by default, otherwise all the newbies will leave them off, and have (relatively speaking) insecure boxes. * Just what is the "scope" of the auditing project under which this change (and many others to come) falls? In other words, how much security do we (FreeBSD) want, and at what expense? Some of the OpenBSD changes have demonstrable security benefits, but they also carry a performance penalty. * Is adding a few bytes to the kernel size really an issue compared to the complexity of having 20 different config options to include/exclude various kernel security features? Personally, I'm quite happy with a policy of "include everything which doesn't have a large performance hit, by default, and have the rest defaulting to 'off' with a trivial way for people to turn it on", but maybe that's just me being a security weenie :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 13:40:35 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 2C264153A5 for ; Mon, 29 Nov 1999 13:40:32 -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 WAA24252 for ; Mon, 29 Nov 1999 22:40:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA66355 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 22:40:31 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id F3D1D153F1 for ; Mon, 29 Nov 1999 13:40:19 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id OAA12181; Mon, 29 Nov 1999 14:40:12 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id OAA20908; Mon, 29 Nov 1999 14:40:11 -0700 Date: Mon, 29 Nov 1999 14:40:11 -0700 Message-Id: <199911292140.OAA20908@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , Matthew Dillon , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: References: <199911291829.LAA19811@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > where is the other discussion going on? It was one that Matt and I were having, which paralled some of the other discussions that were going on on -arch this morning. Rather than continue it, I decided to just hold off and see what falls out of the discussions you and Daniel were having.... Nate > > On Mon, 29 Nov 1999, Nate Williams wrote: > > > [ Threading definitions and such ] > > > > While I'm enjoying the conversation, and I believe there's more to talk > > about, I'm going to withdraw from the discussion simply because I don't > > want to fragment the discussion too much. > > > > There is a *LOT* of other conversations happening on this topic, and > > rather than try and keep that many balls in the air, I'd like to focus > > in on what everyone else is talking about. > > > > Plus it appears that the other discussions are starting to converge and > > deal with these issues as well. > > > > > > > > Nate > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 14: 8:16 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 1BFF414FAF for ; Mon, 29 Nov 1999 14:08:13 -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 XAA24491 for ; Mon, 29 Nov 1999 23:08:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA66477 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 23:08:12 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 79D6714FAF for ; Mon, 29 Nov 1999 14:07:30 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id XAA10798 for arch@FreeBSD.ORG; Mon, 29 Nov 1999 23:07:25 +0100 (CET) Date: Mon, 29 Nov 1999 23:07:25 +0100 From: Martin Cracauer To: arch@freebsd.org Subject: Re: What to do about "subscript has type `char'" warnings? Message-ID: <19991129230725.B10767@cons.org> References: <19991129201610.A9998@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <19991129201610.A9998@cons.org>; from Martin Cracauer on Mon, Nov 29, 1999 at 08:16:11PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to point out that the code in question is 100% correct, because the indexing is guaranteed to be < 128. I only want to kill the warning, but in the least obscure way and not killing other warnings that may come up in future. In <19991129201610.A9998@cons.org>, Martin Cracauer wrote: > Newest compiler now produces a lot of "subscript has type `char'" > warnings for sh (its syntax table). > > I would change direct appearences of > char bla; > string[bla]; > to > int bla; > string[bla]; > which IMHO is consistent with ANSI C and its int and char properties. > > A different matter is an index that is a followed pointer to a char; > char *s = syntax[2]; > string[*s]; > > I could either > a) use an additional int variable, which causes some > overhead, of course > b) or cast > char *s = syntax[2]; > string[(int)*s]; > > I tend to cast for the second case, although it's a little > inconsistent with the fix for the direct case. Opinions? > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer http://www.cons.org/cracauer/ > Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 17:13:36 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 5E1FA1563B for ; Mon, 29 Nov 1999 17:13:18 -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 CAA26337 for ; Tue, 30 Nov 1999 02:13:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA67652 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 02:13:15 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C41B2155A4 for ; Mon, 29 Nov 1999 17:11:38 -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 RAA67964; Mon, 29 Nov 1999 17:11:33 -0800 (PST) Date: Mon, 29 Nov 1999 17:11:33 -0800 (PST) From: Julian Elischer To: Peter Wemm Cc: arch@freebsd.org Subject: Re: Threads stuff - reality check.. In-Reply-To: <19991129144125.C7E121CC6@overcee.netplex.com.au> 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 Mon, 29 Nov 1999, Peter Wemm wrote: > I'd hate to ruin a good pie-in-the-sky session on the design of the killer > threads system and all, but I kinda wonder if we're aiming too hight to start > with? Certainly that would be nice but I'm afraid that if we do it we'll be 'stuck' with it.. also remember that all teh linuxthreads stuff is GPL'd so it would mean a rewrite. > > Wouldn't it be better to put the pieces that we already have together and > make something in time for 4.0 that runs with better concurrency than we > have now? ie: perhaps based on Richard's native linuxthreads port? > > Most of the pieces are there, but it needs work to tidy up the loose ends > and bring it up to date, and probably some debugging to get it to work > properly. There isn't a chance in hell that the Ultimate Threads are going > to be ready for 4.0, but we have got a pretty good shot at doing an > intermediate version that's at least comparable to what Linux does. Things > like squid etc really hurt without threads with blocking support, and it > will be a damn shame to miss the opportunity to have an alternative to > uthreads in 4.0. Most of the work is already done after all. It doesn't > take much to get the kit from http://lt.tar.com/ to compile and > pretty much work. > > Many of the primatives and infrastructure would be *directly* applicable to the > new threads - eg: reentrancy support in libc etc. > > Cheers, > -Peter > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 17:51:38 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 BC3DF156FB for ; Mon, 29 Nov 1999 17:50:30 -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 CAA26665 for ; Tue, 30 Nov 1999 02:50:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA67806 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 02:50:28 +0100 (MET) Received: from 24-25-220-29.san.rr.com (24-25-220-29.san.rr.com [24.25.220.29]) by hub.freebsd.org (Postfix) with ESMTP id CD12615666; Mon, 29 Nov 1999 17:48:01 -0800 (PST) (envelope-from Doug@gorean.org) Received: from gateway.gorean.org (gateway.gorean.org [10.0.0.1]) by 24-25-220-29.san.rr.com (8.9.3/8.8.8) with ESMTP id RAA32993; Mon, 29 Nov 1999 17:48:00 -0800 (PST) (envelope-from Doug@gorean.org) Date: Mon, 29 Nov 1999 17:47:30 -0800 (PST) From: Doug Barton X-Sender: doug@24-25-220-29.san.rr.com To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: 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 Mon, 29 Nov 1999, Kris Kennaway wrote: > On Mon, 29 Nov 1999, Matthew Dillon wrote: > > > Hi Dan. Is it possible that we could adjust this feature to be enabled > > with a config option? It seems to add a considerable amount of bulk to > > the kernel that's deadweight for the people not using it. > > This raises some larger architectural issues which probably should be > dealt with. Namely: > > * Changes which tighten security are arguably only useful if they're on by > default, otherwise all the newbies will leave them off, and have > (relatively speaking) insecure boxes. Personally I agree with this principle, and agree that options of this sort should be on by default. > * Just what is the "scope" of the auditing project under which this change > (and many others to come) falls? In other words, how much security do we > (FreeBSD) want, and at what expense? Some of the OpenBSD changes have > demonstrable security benefits, but they also carry a performance penalty. Any security feature that can cause a performance hit (and we can argue that definition another time) should be optionable, including "small ones." I have some systems where _every_ cpu cycle is non-trivial, so I want the ability to push some of my security downstream and just let the box do its job. > * Is adding a few bytes to the kernel size really an issue compared to the > complexity of having 20 different config options to include/exclude > various kernel security features? Sorry, "kernel option complexity" is a red-herring argument. If the options are well thought out, given sensible defaults and thoroughly documented that whole argument just dries up and blows away. This isn't microsoft, and we're not pushing a "one best way" on our users. My feeling is that _every_ kernel option should have a compile/link-time component (whether that is config-able, or fits into whatever new structure we come up with) AND a sysctl knob wherever possible. Just because this hasn't been done in the past doesn't mean this isn't a good time to start. As for random pids, I would turn this off with extreme prejudice. I don't think it gains us much, if anything (and yes, I understand the /tmp race arguments, I just think they are better solved elsewhere) and as Mark Murray said in relation to the forth boot password thing, bad security is worse than none. I do think that random source port numbers is a bonus, for the reasons that Warner already addressed, and because it makes spoofing packets _coming_ from your machine somewhat harder. FWIW, Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 18: 0:44 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 543F914EEF for ; Mon, 29 Nov 1999 18:00:37 -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 DAA26752 for ; Tue, 30 Nov 1999 03:00:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67879 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 03:00:37 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id E12BB15691; Mon, 29 Nov 1999 17:58:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id CE9BE1CD623; Mon, 29 Nov 1999 17:58:59 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 17:58:59 -0800 (PST) From: Kris Kennaway To: Doug Barton Cc: Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: 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 Mon, 29 Nov 1999, Doug Barton wrote: > > * Is adding a few bytes to the kernel size really an issue compared to the > > complexity of having 20 different config options to include/exclude > > various kernel security features? > > Sorry, "kernel option complexity" is a red-herring argument. If > the options are well thought out, given sensible defaults and thoroughly > documented that whole argument just dries up and blows away. This isn't This doesn't seem to be the way other people have been pushing..I'm pretty sure there have been cases recently where it was decided against making a new feature a config option on the grounds of #ifdef HELL. For large changes I definitely agree, but not for trivial (e.g. 1-line, like this one) changes. There will probably end up being 20 or so randomized features in the kernel, most of them trivial (~1 line) patches. As long as they're sysctl'able, is it really necessary to have each of them optionable? > As for random pids, I would turn this off with extreme > prejudice. I don't think it gains us much, if anything (and yes, I > understand the /tmp race arguments, I just think they are better solved > elsewhere) and as Mark Murray said in relation to the forth boot password I'd appreciate some suggestions about how we can fix them in the case of third-party binaries (esp. statically-linked ones). > thing, bad security is worse than none. I agree, but I don't think it applies in this case. It converts a trivially exploitable hole into a quite difficult to exploit race, which is the best I can think of, and measurably improves security. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 18: 0:50 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 2246715697 for ; Mon, 29 Nov 1999 18:00:44 -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 DAA26759 for ; Tue, 30 Nov 1999 03:00:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67893 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 03:00:43 +0100 (MET) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id F0C0B15698; Mon, 29 Nov 1999 17:59:12 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA88178; Mon, 29 Nov 1999 17:59:10 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Mon, 29 Nov 1999 13:27:42 PST." Date: Mon, 29 Nov 1999 17:59:10 -0800 Message-ID: <88174.943927150@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Changes which tighten security are arguably only useful if they're on by > default, otherwise all the newbies will leave them off, and have > (relatively speaking) insecure boxes. That's highly arguable. We provide secure levels, for example, but if we turned them on to any appreciable degree then people's X servers wouldn't work because we have no aperture driver. Would it be correct in the general case? Yes. Would it be correct for workstation users? No. Such is also the case in numerous other situations and it really is a question of providing mechanisms which people can use selectively, not just in providing the best "out of box" security defaults. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 18: 7:21 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 16A8E1569C for ; Mon, 29 Nov 1999 18:06:34 -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 DAA26799 for ; Tue, 30 Nov 1999 03:06:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67945 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 03:06:33 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E17AC14A21; Mon, 29 Nov 1999 18:05:16 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA13833; Mon, 29 Nov 1999 18:05:16 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 18:05:16 -0800 (PST) From: Matthew Dillon Message-Id: <199911300205.SAA13833@apollo.backplane.com> To: Kris Kennaway Cc: Doug Barton , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :There will probably end up being 20 or so randomized features in the :kernel, most of them trivial (~1 line) patches. As long as they're :sysctl'able, is it really necessary to have each of them optionable? What if we just has a general security randomization option that applied to all of them, and then a sysctl to cover each of them? That would cover my concerns. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 18: 9:14 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 186461569E for ; Mon, 29 Nov 1999 18:08:35 -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 DAA26824 for ; Tue, 30 Nov 1999 03:08:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA67975 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 03:08:34 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 9F135156EF for ; Mon, 29 Nov 1999 18:08:10 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id VAA33414; Mon, 29 Nov 1999 21:06:35 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Mon, 29 Nov 1999 21:06:34 -0500 (EST) From: Chuck Robey To: "Daniel M. Eischen" Cc: Matthew Dillon , Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <3842B7EE.F0D02992@vigrid.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 No context here, because I want to ask another question regarding the proposals, but it's context is too stale to repeat. I've finished reading the SA paper, and one question bothers me. It looks like the kernel is making upcalls into the UTS. It further looks like there could be multiple copies of the UTS active, either because of multiple processors, unsynchronized process swaps of processes with UTS's that are active, and upcalls coming in before a previous upcall can clear the UTS. I did see that the UTS is required under SA to be re-entrant (obviously) but I didn't see any synchronization requirements on the UTS specified, and it does look like it would need some global state that would need protection. Did I miss that part of the paper? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 19:48:53 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 33ECB1570D for ; Mon, 29 Nov 1999 19:48:00 -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 EAA27460 for ; Tue, 30 Nov 1999 04:47:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA68243 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 04:47:58 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0F40715717 for ; Mon, 29 Nov 1999 19:47:43 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt1.pcnet.net [206.105.29.75]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id WAA03497; Mon, 29 Nov 1999 22:47:33 -0500 (EST) Message-ID: <38434896.84693F95@vigrid.com> Date: Mon, 29 Nov 1999 22:46:30 -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: Chuck Robey Cc: Matthew Dillon , Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Robey wrote: > > No context here, because I want to ask another question regarding the > proposals, but it's context is too stale to repeat. I've finished reading > the SA paper, and one question bothers me. > > It looks like the kernel is making upcalls into the UTS. It further looks > like there could be multiple copies of the UTS active, either because of > multiple processors, unsynchronized process swaps of processes with UTS's > that are active, and upcalls coming in before a previous upcall can clear > the UTS. I did see that the UTS is required under SA to be re-entrant > (obviously) but I didn't see any synchronization requirements on the UTS > specified, and it does look like it would need some global state that > would need protection. The same rules apply to upcalls to the UTS as other threads. Critical regions must be protected with spinlocks or something similar. If the UTS, or any other thread, is preempted because the respective subprocess consumed its quantum, then at the next opportunity on another subprocess, an upcall is made notifying the UTS of the preemption. The UTS will check the program counter of the preempted thread (or flag set in the thread structure) to see if it was in a critical region. If it was, the UTS will resume it to the point that it leaves the critical region. We may want to limit the time spent spinning and make an explicit check for preemption, so that the entire subprocess quantum isn't consumed waiting for the next subprocess to run. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 19:54:28 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 9A08515719 for ; Mon, 29 Nov 1999 19:54:22 -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 EAA27513 for ; Tue, 30 Nov 1999 04:54:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA68294 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 04:54:21 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id CA72B1578E; Mon, 29 Nov 1999 19:53:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BDDB61CD736; Mon, 29 Nov 1999 19:53:09 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 19:53:09 -0800 (PST) From: Kris Kennaway To: "Jordan K. Hubbard" Cc: Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <88174.943927150@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > That's highly arguable. We provide secure levels, for example, but if > we turned them on to any appreciable degree then people's X servers > wouldn't work because we have no aperture driver. Would it be correct > in the general case? Yes. Would it be correct for workstation users? > No. Such is also the case in numerous other situations and it really > is a question of providing mechanisms which people can use selectively, > not just in providing the best "out of box" security defaults. This would fall under my preferred policy, which you didn't quote, namely "turn on everything which doesn't have a negative impact, and providing an easy mechanism to enable everything else". Preventing X from running is something many (though not all :) people would consider negative :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 20: 4:11 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 0D24D156BB for ; Mon, 29 Nov 1999 20:03:32 -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 FAA27595 for ; Tue, 30 Nov 1999 05:03:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA68355 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 05:03:31 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 21BF715759; Mon, 29 Nov 1999 20:03:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5E1CD41E; Mon, 29 Nov 1999 20:02:59 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Mon, 29 Nov 1999 20:02:59 -0800 (PST) From: Kris Kennaway To: Matthew Dillon Cc: Doug Barton , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <199911300205.SAA13833@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 Mon, 29 Nov 1999, Matthew Dillon wrote: > :There will probably end up being 20 or so randomized features in the > :kernel, most of them trivial (~1 line) patches. As long as they're > :sysctl'able, is it really necessary to have each of them optionable? > > What if we just has a general security randomization option that > applied to all of them, and then a sysctl to cover each of them? > That would cover my concerns. Hmm. I think this would be an acceptable compromise provided it's in GENERIC. Boot floppies and the anti-bloat brigade can leave it out if they want to save that extra 1k :-) The only thing is that in many cases we'd end up doing the equivalent of: #ifdef RANDOM_SECURITY i = arc4random(); #else i = random(); #endif Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 21: 3:29 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 D63FD14C17 for ; Mon, 29 Nov 1999 21:03:24 -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 GAA28111 for ; Tue, 30 Nov 1999 06:03:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA68544 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 06:03:23 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 7BAD415768 for ; Mon, 29 Nov 1999 21:02:57 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA38443; Tue, 30 Nov 1999 00:01:40 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Tue, 30 Nov 1999 00:01:40 -0500 (EST) From: Chuck Robey To: "Daniel M. Eischen" Cc: Matthew Dillon , Nate Williams , Julian Elischer , Jason Evans , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <38434896.84693F95@vigrid.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 Mon, 29 Nov 1999, Daniel M. Eischen wrote: > > It looks like the kernel is making upcalls into the UTS. It further looks > > like there could be multiple copies of the UTS active, either because of > > multiple processors, unsynchronized process swaps of processes with UTS's > > that are active, and upcalls coming in before a previous upcall can clear > > the UTS. I did see that the UTS is required under SA to be re-entrant > > (obviously) but I didn't see any synchronization requirements on the UTS > > specified, and it does look like it would need some global state that > > would need protection. > > The same rules apply to upcalls to the UTS as other threads. Critical > regions must be protected with spinlocks or something similar. If the > UTS, or any other thread, is preempted because the respective subprocess > consumed its quantum, then at the next opportunity on another subprocess, > an upcall is made notifying the UTS of the preemption. The UTS will > check the program counter of the preempted thread (or flag set in > the thread structure) to see if it was in a critical region. If it > was, the UTS will resume it to the point that it leaves the critical > region. > > We may want to limit the time spent spinning and make an explicit check > for preemption, so that the entire subprocess quantum isn't consumed > waiting for the next subprocess to run. Scenario: UTS on processor 1 is stopped due to a page fault, while it's in a critical section. UTS on processor 2 is entering a critical section, a spin lock which will end up in conflict with the processor 1 UTS, when it gets the upcall, telling it that processor 1 has a suspended UTS, so that this second UTS is pretty much dead in the water. If it's possible for a UTS to get a page fault (or any other unpredictable swap-out) during a critical section may be a really bad idea. If it's possible for threaded process to run on multiple processors in time slots that *aren't* synchronous, then deadlocks would be a problem there too. The difference I see between UTS threads, as against all other threads, is that all other threads implicitly depend on the UTS, so the UTS can't hang without serious performance impacts. Isn't this a problem for SA implementations? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 21:35: 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 79F9C15424 for ; Mon, 29 Nov 1999 21:35:01 -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 GAA28465 for ; Tue, 30 Nov 1999 06:35:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA68609 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 06:35:00 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7706915424 for ; Mon, 29 Nov 1999 21:34:50 -0800 (PST) (envelope-from julian@whistle.com) Received: from home.elischer.org (home.elischer.org [207.76.204.203]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA73625; Mon, 29 Nov 1999 21:34:41 -0800 (PST) Date: Mon, 29 Nov 1999 21:34:40 -0800 (PST) From: Julian Elischer X-Sender: julian@home.elischer.org To: Chuck Robey Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: 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 Tue, 30 Nov 1999, Chuck Robey wrote: > > Scenario: UTS on processor 1 is stopped due to a page fault, while it's in > a critical section. UTS on processor 2 is entering a critical section, a > spin lock which will end up in conflict with the processor 1 UTS, when it > gets the upcall, telling it that processor 1 has a suspended UTS, so that > this second UTS is pretty much dead in the water. > > If it's possible for a UTS to get a page fault (or any other unpredictable > swap-out) during a critical section may be a really bad idea. If it's > possible for threaded process to run on multiple processors in time slots > that *aren't* synchronous, then deadlocks would be a problem there too. > > The difference I see between UTS threads, as against all other threads, is > that all other threads implicitly depend on the UTS, so the UTS can't hang > without serious performance impacts. Isn't this a problem for SA > implementations? My take on this is as follows: The UTS has some sort of structure that is private to itself. it also has a descriptor for each thread, and each thread has a stack on which there is some saved context. The kernel needs to know that when the UTS is blocking it should NOT perform an upcall. The result of this is that yes, the UTS actually blocks. However this should only happen at startup because the UTS will be hot code and data. The kernle knows it's the UTS because it knows where the UTS's stack is and cna check whether the blocking thread is on that stack. Other time s that the UTS might block in a pagefault are when loading context from the incoming thread's stack (it may have been paged out.) and when reading the structure describing that thread. In the first case, the UTS is about to relinquish control of the processor to the incomng thread, so we can move it's stack pointer to a location within the new stack already. This nesures that it will not be recognised as being the UTS and some other thread will be given the oportunity to run while the page is being brought in. The second is a bit more difficult, because the UTS may need to read this structure while doing more mundane tasks, (e,g figuring out who to run). However this structure is quite a bit smaller. it is possible that the page on which it sits will alway be in core as somewhere else on it is a thread that get's called more often. Still we need to keep this page resident. It is possible that we may be able to do some mmapp or sysvSHM trick to keep this small region in core. Failing this we may just need to block. I'm not sure that a goal of teh thread system is to have the programs NEVER EVER EVER block. What iof the whole program is swapped out at a busy time? What we can do however is make it pretty dammed unlikely, by keeping these structures small and in hot pages. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 22:11:31 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 AB60814CAA for ; Mon, 29 Nov 1999 22:11:29 -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 HAA28681 for ; Tue, 30 Nov 1999 07:11:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA68709 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 07:11:27 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 08E251577A for ; Mon, 29 Nov 1999 22:11:07 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id BAA38602; Tue, 30 Nov 1999 01:10:07 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Tue, 30 Nov 1999 01:10:07 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: 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 Mon, 29 Nov 1999, Julian Elischer wrote: > > The difference I see between UTS threads, as against all other threads, is > > that all other threads implicitly depend on the UTS, so the UTS can't hang > > without serious performance impacts. Isn't this a problem for SA > > implementations? > > My take on this is as follows: > The UTS has some sort of structure that is private to itself. > it also has a descriptor for each thread, > and each thread has a stack on which there is some saved context. > > The kernel needs to know that when the UTS is blocking it should NOT > perform an upcall. The result of this is that yes, the UTS actually > blocks. However this should only happen at startup because the UTS will be > hot code and data. The kernle knows it's the UTS because it knows where > the UTS's stack is and cna check whether the blocking thread is on that > stack. Other time s that the UTS might block in a pagefault are when > loading context from the incoming thread's stack (it may have been paged > out.) and when reading the structure describing that thread. > > In the first case, the UTS is about to relinquish control of the processor > to the incomng thread, so we can move it's stack pointer to a location > within the new stack already. This nesures that it will not be recognised > as being the UTS and some other thread will be given the oportunity to run > while the page is being brought in. The second is a bit more difficult, > because the UTS may need to read this structure while doing more mundane > tasks, (e,g figuring out who to run). However this structure is quite a > bit smaller. it is possible that the page on which it sits will alway be > in core as somewhere else on it is a thread that get's called more > often. Still we need to keep this page resident. It is possible that > we may be able to do some mmapp or sysvSHM trick to keep this small region > in core. Failing this we may just need to block. I'm not sure that a goal > of teh thread system is to have the programs NEVER EVER EVER block. > What iof the whole program is swapped out at a busy time? > > What we can do however is make it pretty dammed unlikely, by keeping these > structures small and in hot pages. If one of those strategies is used to ensure that the UTS never swaps, then will we also be sure that, when a threaded process is running on two different processors, that the timing will be synchronous (both processors threaded process timeslots exactly coincide) so that one UTS can never block waiting for a non-running UTS to come back? The argument I'd heard ealier was that we wanted to have threads spread across as many processors as possible, but this seems to mean that they must happen at the same time (or else not hold locks when being switched out). I see that there are two possibilities for one UTS to be sleeping, when another wants to utilize shared state: (1) a UTS takes a page fault, or (2), a UTS takes a process context switch. You've explained (1) fine for me (assuming one of the forced-residency strategies is followed). I think (2) may end up being a requirement. Are there any other cases where the execution of UTSs get out of sync? ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 22:45:39 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 7A9F715792 for ; Mon, 29 Nov 1999 22:45:36 -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 HAA29018 for ; Tue, 30 Nov 1999 07:45:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA68836 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 07:45:36 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 68EBB15792 for ; Mon, 29 Nov 1999 22:45:29 -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 WAA74907 for ; Mon, 29 Nov 1999 22:45:28 -0800 (PST) Date: Mon, 29 Nov 1999 22:45:28 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Revisitted.. Threads goals.? In-Reply-To: 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 I think this is a good time for us to re-examine some of the things that we decided were goals. I have somme comments I'd like to make AT THE END, but after the general neuron frying of the last week or so it might be a good idea to look at these again and see if any of them have changed in light of the discussion. I have difficulty in seeing this list as exhaustive or correct. We need someone who is very into threads to contribute. Jason? What do yuo see as YOUR goals? -----last version of the goals I have in my mailbox.---- 1/ Multiple independent 'threads of control' within a single process at user level. The most basic quality of threads. 2/ Ability to simultaneously schedule M threads over N Processors, and have min(M,N) threads simultaneously executing. 2A/ ability to tune and control the above.. 3/ Just because one thread blocks, doesn't mean that the others can't keep running. 4/ All threads in a processs see the same address space (exactly). 4A/ All threads in a process share the same system resources, except cpu which is treated specially, and some as yet unspecified thread specific uniqifier. 5/ A process may be able to group threads into classes that have different system priorities. These classes can not have priorities greater than the process itself or a child could achieve, and should be treatable by the system as a separate child process from a scheduling point of view (including limits). 5A/ As a result threaded processes should have no more capability to swamp a system than a regular forking process. 6/ Some well documeted scheme exists for handling signals and other async events. 7/ Exit/shutdown protocol is well defined. 8/ The allocation of user level threads to thread groups is opaque to the kernel. 9/ Quick access to curthread and thread specific data. 10/ A method to ask a thread blocked in the kernel to wake up and back out (similar to present 'signals'). (see 6, 7) ---- possible userland implementation goals----- 1/ A libpthread that can be linked with libc. 2/ Libc needs to change so that library functions and system calls used internal to the library do not use the externally visible cancellable equivalents. 3/ see 8 above. ------------- Meta-goals ------------- We should keep our eyes on: *) scalability *) performance *) ability to support features required by standards based threads. *) ability to support features of those thread packages we select as needed. --------------------------- COMMENTS: Peter made a valid point which is that maybe we should figure out a waypoint between here and there, that gives us a working but sub-optimal threads package of the order of the linux threads package, that can be included in 4.0 We may have 2 whole months to get that done :-( Also, Matt Dillon has been arguing strongly that point 8 (kernel) and point 3(user) are non goals, in fact he wants the opposite. He also argues that making an entity that groups KSE's on a scale smaller than the entire process is a bad idea. I disagree but we haven't decided anyting yet. He claims 'simplicity. I think that he may be sliding back up teh other side of th ecurve by trying to simplify more than the goals (many of which we are inherritting from Posix via the 3rd meta-goal) allow. how would we move towards Peter's hope? and are there things we can do that there is no argument about? I think that separating the proc structure is agreed, but it is not needed for Linux threads.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 29 23: 2:21 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 7A22E152C8 for ; Mon, 29 Nov 1999 23:02:14 -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 IAA29206 for ; Tue, 30 Nov 1999 08:02:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA68966 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 08:02:04 +0100 (MET) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 9F9E015150; Mon, 29 Nov 1999 23:01:56 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA89019; Mon, 29 Nov 1999 23:01:53 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kris Kennaway Cc: Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Mon, 29 Nov 1999 19:53:09 PST." Date: Mon, 29 Nov 1999 23:01:53 -0800 Message-ID: <89015.943945313@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This would fall under my preferred policy, which you didn't quote, namely > "turn on everything which doesn't have a negative impact, and providing Not being able to predict pids (for useful purposes) would fall under the definition of "negative impact" for a number of admins. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 4: 4:13 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 4B50D152AC for ; Tue, 30 Nov 1999 04:04:06 -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 NAA04212 for ; Tue, 30 Nov 1999 13:03:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA69897 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 13:03:56 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 9B3131573E for ; Tue, 30 Nov 1999 04:03:36 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt46.pcnet.net [206.105.29.120]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA23878; Tue, 30 Nov 1999 07:03:34 -0500 (EST) Message-ID: <3843BCE0.4BB7001C@vigrid.com> Date: Tue, 30 Nov 1999 07:02:40 -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: Chuck Robey Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [CC list trimmed] Chuck Robey wrote: > > Scenario: UTS on processor 1 is stopped due to a page fault, while it's in > a critical section. UTS on processor 2 is entering a critical section, a > spin lock which will end up in conflict with the processor 1 UTS, when it > gets the upcall, telling it that processor 1 has a suspended UTS, so that > this second UTS is pretty much dead in the water. > > If it's possible for a UTS to get a page fault (or any other unpredictable > swap-out) during a critical section may be a really bad idea. If it's > possible for threaded process to run on multiple processors in time slots > that *aren't* synchronous, then deadlocks would be a problem there too. > > The difference I see between UTS threads, as against all other threads, is > that all other threads implicitly depend on the UTS, so the UTS can't hang > without serious performance impacts. Isn't this a problem for SA > implementations? The problem is not specific to SA; you can page fault in a critical region (fiddling with one of the user-level scheduling queues, for instance) regardless of whether you are using scheduler activations. The UTS will be doing pretty much the same things every time, so it is hoped that the pages will stay resident and not get swapped out often. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 4:21:49 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 0563215884 for ; Tue, 30 Nov 1999 04:21:44 -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 NAA04507 for ; Tue, 30 Nov 1999 13:21:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA69958 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 13:21:43 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id E1E7F15884 for ; Tue, 30 Nov 1999 04:20:34 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt11.pcnet.net [206.105.29.85]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA25672; Tue, 30 Nov 1999 07:20:34 -0500 (EST) Message-ID: <3843C0DD.DD80682D@vigrid.com> Date: Tue, 30 Nov 1999 07:19:41 -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: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Revisitted.. Threads goals.? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Peter made a valid point which is that maybe we should figure out > a waypoint between here and there, that gives us a working but > sub-optimal threads package of the order of the linux threads package, > that can be included in 4.0 > > We may have 2 whole months to get that done :-( Isn't Feature Freeze December 15th? That's only 2 weeks. > Also, Matt Dillon has been arguing strongly that point 8 (kernel) > and point 3(user) are non goals, in fact he wants the opposite. > He also argues that making an entity that groups KSE's on a scale smaller > than the entire process is a bad idea. I disagree but we haven't > decided anyting yet. He claims 'simplicity. I think that he may be sliding > back up teh other side of th ecurve by trying to simplify more than the > goals (many of which we are inherritting from Posix via the 3rd meta-goal) > allow. > > how would we move towards Peter's hope? and are there things we can do > that there is no argument about? I think that separating the proc > structure is agreed, but it is not needed for Linux threads.. I see you just committed a LinuxThreads port. Shouldn't that be sufficient until 4.1 comes out with some version of our native threads? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 4:35:34 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 2337415150 for ; Tue, 30 Nov 1999 04:35:31 -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 NAA04769 for ; Tue, 30 Nov 1999 13:35:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA70007 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 13:35:29 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id C981115150 for ; Tue, 30 Nov 1999 04:35:03 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA23448; Tue, 30 Nov 1999 23:43:02 +1100 Date: Tue, 30 Nov 1999 23:34:41 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Martin Cracauer Cc: arch@freebsd.org Subject: Re: What to do about "subscript has type `char'" warnings? In-Reply-To: <19991129230725.B10767@cons.org> 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 Mon, 29 Nov 1999, Martin Cracauer wrote: > I'd like to point out that the code in question is 100% correct, > because the indexing is guaranteed to be < 128. And >= 0? > I only want to kill the warning, but in the least obscure way and not > killing other warnings that may come up in future. Cast the indexes to int. This is the least obscure way of hinting that the code actually knows what it is doing when it packs small integers into chars. Casting to unsigned char would hint that the range is [0..255] and that the code is too sloppy to use unsigned char for the arrays. Plain char is better than unsigned char if it has adequate range, since it is more likely to be the most efficient char type. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 5:16:36 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 EBBB614D80 for ; Tue, 30 Nov 1999 05:16:31 -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 OAA05376 for ; Tue, 30 Nov 1999 14:16:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA70162 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 14:16:24 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 4572714D80 for ; Tue, 30 Nov 1999 05:16:12 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id HAA11368; Tue, 30 Nov 1999 07:16:09 -0600 (CST) (envelope-from dick) Date: Tue, 30 Nov 1999 07:16:09 -0600 From: "Richard Seaman, Jr." To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Revisitted.. Threads goals.? Message-ID: <19991130071609.J29767@tar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 29, 1999 at 10:45:28PM -0800, Julian Elischer wrote: > --------------------------- > COMMENTS: > > Peter made a valid point which is that maybe we should figure out > a waypoint between here and there, that gives us a working but > sub-optimal threads package of the order of the linux threads package, > that can be included in 4.0 > > We may have 2 whole months to get that done :-( [snip] > how would we move towards Peter's hope? and are there things we can do > that there is no argument about? I think that separating the proc > structure is agreed, but it is not needed for Linux threads.. I've attached a private email I sent to Jason Evans last week related to this subject: From dick@tar.com Wed Nov 24 08:25:27 1999 Date: Wed, 24 Nov 1999 08:25:27 -0600 From: "Richard Seaman, Jr." To: Jason Evans Subject: Re: Threads and my new job. Message-ID: <19991124082527.F1408@tar.com> References: <19991122185220.D301@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <19991122185220.D301@sturm.canonware.com> Status: RO Content-Length: 4825 Lines: 112 On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote: > Walnut Creek has hired me as a full time employee to work primarily on > improving and expanding FreeBSD's threads support. This is very exciting > to me, and I hope my work will be of benefit the FreeBSD community. This is great news. > There is a lot of work to be done in order to make FreeBSD's threads > support truly excellent, For sure. About 9 months ago I spend some time thinking about the FBSD threads library and how to upgrade it. I concluded that one way to go was as follows: 1) Add "kernel thread" support to the existing uthread library, so that a user at run time could create either "user threads" or "kernel threads" (ie. PTHREAD_SCOPE_PROCESS or PTHREAD_SCOPE_SYSTEM). Initially all threads in a process would have to be one or the other, ie. they couldn't be mixed within a process. At the same time, possibly split the uthread code into libpthread so it links to libc. The "kernel threads" would be rforked processes (or _clone'd processes similar to what exists in the linuxthreads port (see http://lt.tar.com). SMP threading would be supported. 2) As stage 2, make the kernel mods that would permit more efficient user threads, as well as mix and match user/kernel threads (of KSE's), along the lines of the recent discussion in the -arch mailing list. The logic for the two step process was that most (but not all) of the work to do step 1 is work that you will have to do to complete step 2 even if you integrate the steps. Also, the detailed code review in step 1 would help you define the specific details of the kind of kernel support you need to implement step 2. Also, there would be a faster payoff from your work. I'd guess that 90-95% of threaded apps really benefit from either kernel threads or user threads, but the mix/match, which is much more complex, only benefits a small percent of real world apps. I think the existing uthread code can be split into four categories: 1) Generic pthread code that works regardless of the threads model. There is a lot of code in this category. 2) Code that is needed only for "user thread" syscall blocking. This might well be 50% or more of the code. It is not needed for kernel threads, and if you add scheduler activations, or some other kernel notification scheme regarding blocked syscalls, this code just drops out of the user thread case as well. You'll get great code simplification and much better performance. My concept was to encapsulate this portion of the code with a flag like: if (_need_syscall_blocking_code) { ........ } Then, if you create a kernel thread, you require (for step 1 purposes) all subsequent threads to be kernel threads and you set _need_syscall_blocking_code to FALSE. Of course, when you implement step 2, this code goes away. This is code analysis and segregation you need to do at some point. 3) Code that is "user thread" specific. This is primarily code that is user thread scheduler related. This would be encapsulated with a flag like "_have_uthreads" similar to the above. This is code you will have to segregate, analyse, and probably modify substantially for step 2. Isolating it early doesn't hurt, and the review may give you a much better grip on the details you need when you implement step 2. 4) Code that is related to libc's lack of thread support. Specifically the abscence of locks for the FILE structure (other libc structures need locks too). This code should eventually go away if libc is improved to better support threads. There's no need to flag this code for execution purposes, but it might help to mark it somehow for future reference. 5) You would have to add (and flag) the new kernel thread code. However, I think this would be very minimal. Creating rforked kernel threads is really very simple, and as long as you're not grafting multiple user threads on each kernel thread, you need almost no support in the pthread library. This new code would either drop out or need to be rewritten for step 2, and thus would be something of a waste. But, I'd guess it might take 2 days of so of coding (plus testing) to do. There would be a side benefit though, in that you'd have some code to test against when you get to step 2. You could test for performance as well as bugs. Your step 2 code is going to be much more complex and bug prone, so you may want a more stable reference for testing. I guessed that all of step 1 was roughly a man month of work. Maybe 1 week of coding/analysis, and 3 weeks of testing/debugging. Splitting libc might add more to this. Please use these thoughts as you see fit. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 5:45:19 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 AAEDC158A0 for ; Tue, 30 Nov 1999 05:45:12 -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 OAA05857 for ; Tue, 30 Nov 1999 14:45:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA70371 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 14:45:10 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1DC5F158A0 for ; Tue, 30 Nov 1999 05:44:59 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p15-dn01kiryunisiki.gunma.ocn.ne.jp [210.132.6.144]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id WAA25492; Tue, 30 Nov 1999 22:44:53 +0900 (JST) Message-ID: <3843D43E.4F40A642@newsguy.com> Date: Tue, 30 Nov 1999 22:42:22 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@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: > > No, it won't, because most context switches are synchronous and > the tick interval doesn't apply in those cases. Asynchronizing > I/O does not necessarily mean that the calling thread will continue to > run. If it has nothing to do it is going to exit or go to sleep whether > the I/O is asynchronous or not. It is definitely not going to waste > cpu finishing out its quanta. Mmmm... that's not exactly what I'm worried about. I'm thinking of applications which use threads to handle both i/o and cpu-bound tasks. Our scheduler raises the i/o-bound tasks priority and lowers cpu-bound tasks priority. With a program using threads to do both, the scheduler would end up treating the process as cpu-bound and lower it's priority. Ok, maybe that's fault of the application design, but still... :-) Processes with enough i/o-bound tasks to actually use up all quanta before running out of threads will suffer from a similar fate. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 7:44:27 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 74B6A15924 for ; Tue, 30 Nov 1999 07:44:22 -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 QAA07900 for ; Tue, 30 Nov 1999 16:44:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA70865 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 16:44:20 +0100 (MET) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id B440315928; Tue, 30 Nov 1999 07:44:10 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 510951C5D; Tue, 30 Nov 1999 09:45:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 4C686381B; Tue, 30 Nov 1999 09:45:14 -0500 (EST) Date: Tue, 30 Nov 1999 09:45:14 -0500 (EST) From: Bill Fumerola To: "Jordan K. Hubbard" Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <89015.943945313@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > Not being able to predict pids (for useful purposes) would fall under > the definition of "negative impact" for a number of admins. Depending on a behavior that isn't defined anywhere and doesn't always work falls in my definition of "negative clue". -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 8:55:43 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 BFE5514CE3 for ; Tue, 30 Nov 1999 08:55:39 -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 RAA08735 for ; Tue, 30 Nov 1999 17:55:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA71227 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 17:55:37 +0100 (MET) Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by hub.freebsd.org (Postfix) with ESMTP id 239C81597F for ; Tue, 30 Nov 1999 08:54:32 -0800 (PST) (envelope-from pulsifer@mediaone.net) Received: from ahp3 (ahp.ne.mediaone.net [24.128.184.250]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id LAA15035 for ; Tue, 30 Nov 1999 11:54:31 -0500 (EST) From: "Allen Pulsifer" To: Subject: RE: Revisitted.. Threads goals.? Date: Tue, 30 Nov 1999 11:54:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please forgive me for sticking my foot into this conversation. I'm new to FreeBSD and have only been following this conversation for a week. I don't pretend to know a lot of the theory, or even how threads and SMP are currently implremented in FreeBSD. Everything I could possibly add to this discussion is probably already assumed and well understood by the people on this list, but sometimes it helps to restate the obvious. If not, please feel free to hit the delete key. To step back even further from what Julian just said, the purpose of implementing threads is to have a resource- efficient method of multitasking. Unix operating systems traditionally use processes to implement multitasking. The process structure provides for system security (via separate, virtual address spaces), fair sharing of resources (via round robin scheduling) and efficient use of resources (via blocking and task switching). However, the implementation of processes makes them resource intensive. They are expensive to create, take a lot of memory, expensive to manage (switch from one to another) and can only communicate with each other primarily though expensive methods such as IPC. [Have I left anything out?] The purpose of threads is to provide a more efficient method of multitasking. The goals of threads are to: 1) minimize the amount of memory that each thread uses, so that many (thousands?) of threads can be created; 2) minimize the amount of work that must be done to switch between treads (both scheduling work and actual task switching); 3) allow threads to efficiently communicate with each other; 4) perform all of the above while still providing system security, and fair and efficient use of resources. To meet these goals, it seems obvious that process structure would be maintained. This allows system security to be maintained, and may also allow fair use of resources to be maintained. (The latter is what Julian is arguing for.) It would also seem obvious that threads must share the same address space. This allows efficient communication between threads, as well as efficient task switching between two threads that share the same address space. (But of course, it doesn't help threads with separate address spaces, and this has implications for optimal thead scheduling.) Given the above, it would finally seem obvious that threads sharing the same address space would live within the same process, and possibly inherit all the rest of the baggage that comes along with that (PID, etc). Part of the discussion that is going on seems to be simply about what things do threads share and what things do they not share. For example, each thread must have its own CPU state (PC, registers, etc) and thread (or user) stack so that it can be executed and suspended as needed. However, all threads associated with a process share the same memory map. Other items may be shared or not shared depending on what you are trying to accomplish. A lot of the decisions are tradeoffs between functionality and efficiency. For example, it would seem desirable to make the unshared structures as small as possible, to minimize memory use; however, that may sacrifice functionality. I am not familiar with all of the structures involved, but maybe someone would make a list: what structures must absolutely be unshared, and what structures can optionally be made unique, and what features or functionality are gained by making them unique? A list like this would assist in the tradeoff analysis and decision making. Implementation details aside, it seems to me that one of the major points Matt Dillion is looking for is the ability for two threads, bound to the same process, to run simultaneously on two different CPU's. This seems to be a very desirable goal, however, the question seems to be, what is the cost of implementing this in terms of complexity and level of effort? Furthermore, while this feature would seem to be desireable, if it were NOT implemented, there maybe some assumptions that could be made by user programs and shared libraries that would make the use of the system less complex and more efficient. For example, if it is guaranteed that two threads bound to a process cannot be executing simultaneously, does that simplify user programming? In addition, if it is guaranteed that a thread will not surrender the CPU to another thread in its same process except at certain well defined times (a voluntary surrender, a system call, a signal) does that simplify user programming even more? Do these gains in simplicity make it worthwile not implementing what might otherwise be a powerful feature? Finally, Matt seems to making some points about how the kernel itself can make use of threads. I admit I don't have the background to understand what he is saying. But aside from having "user" threads run in both user and kernel mode, is it envisioned that the kernel itself will have threads that aren't bound to any user process? Where will those threads be used and how will they be managed? Regardless of whether two "user" or process threads can run simultaneously on two seprate CPU's, it would still seem desireable to allow two purely kernel threads to do this. I know everyone who is active on this list is ten times more knowledgeble and experienced than I am, but I hope some of these thoughts (none of which haven't been said somewhere before) might be helpful. Allen > -----Original Message----- > From: owner-freebsd-arch@FreeBSD.ORG > [mailto:owner-freebsd-arch@FreeBSD.ORG]On Behalf Of Julian Elischer > Sent: Tuesday, November 30, 1999 1:45 AM > To: freebsd-arch@FreeBSD.ORG > Subject: Revisitted.. Threads goals.? > > > > I think this is a good time for us to re-examine some of the things that > we decided were goals. > > I have somme comments I'd like to make AT THE END, but after the general > neuron frying of the last week or so it might be a good idea to look at > these again and see if any of them have changed in light of the > discussion. I have difficulty in seeing this list as exhaustive or > correct. We need someone who is very into threads to contribute. > Jason? What do yuo see as YOUR goals? > > > -----last version of the goals I have in my mailbox.---- > > 1/ Multiple independent 'threads of control' within a single process > at user level. The most basic quality of threads. > > 2/ Ability to simultaneously schedule M threads over N Processors, > and have min(M,N) threads simultaneously executing. > 2A/ ability to tune and control the above.. > > 3/ Just because one thread blocks, doesn't mean that > the others can't keep running. > > 4/ All threads in a processs see the same address space (exactly). > 4A/ All threads in a process share the same system resources, except cpu > which is treated specially, and some as yet unspecified thread > specific uniqifier. > > 5/ A process may be able to group threads into classes that have > different system priorities. These classes can not have priorities > greater than the process itself or a child could achieve, and should > be treatable by the system as a separate child process from a > scheduling point of view (including limits). > 5A/ As a result threaded processes should have no more capability to > swamp a system than a regular forking process. > > 6/ Some well documeted scheme exists for handling signals and other > async events. > > 7/ Exit/shutdown protocol is well defined. > > 8/ The allocation of user level threads to thread groups is opaque to the > kernel. > > 9/ Quick access to curthread and thread specific data. > > 10/ A method to ask a thread blocked in the kernel to wake up and back > out (similar to present 'signals'). (see 6, 7) > > > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. > 3/ see 8 above. > > ------------- > Meta-goals > ------------- > We should keep our eyes on: > *) scalability > *) performance > *) ability to support features required by standards based threads. > *) ability to support features of those thread packages we select as > needed. > --------------------------- > COMMENTS: > > Peter made a valid point which is that maybe we should figure out > a waypoint between here and there, that gives us a working but > sub-optimal threads package of the order of the linux threads package, > that can be included in 4.0 > > We may have 2 whole months to get that done :-( > > > Also, Matt Dillon has been arguing strongly that point 8 (kernel) > and point 3(user) are non goals, in fact he wants the opposite. > He also argues that making an entity that groups KSE's on a scale smaller > than the entire process is a bad idea. I disagree but we haven't > decided anyting yet. He claims 'simplicity. I think that he may be sliding > back up teh other side of th ecurve by trying to simplify more than the > goals (many of which we are inherritting from Posix via the 3rd meta-goal) > allow. > > how would we move towards Peter's hope? and are there things we can do > that there is no argument about? I think that separating the proc > structure is agreed, but it is not needed for Linux threads.. > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 9:20:37 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 3FF2F14E52 for ; Tue, 30 Nov 1999 09:20:33 -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 SAA08996 for ; Tue, 30 Nov 1999 18:20:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71358 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:20:31 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CB39514E66; Tue, 30 Nov 1999 09:20:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA25777; Tue, 30 Nov 1999 09:20:21 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 09:20:21 -0800 (PST) From: Matthew Dillon Message-Id: <199911301720.JAA25777@apollo.backplane.com> To: Bill Fumerola Cc: "Jordan K. Hubbard" , Kris Kennaway , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Not being able to predict pids (for useful purposes) would fall under :> the definition of "negative impact" for a number of admins. : :Depending on a behavior that isn't defined anywhere and doesn't :always work falls in my definition of "negative clue". : :-- :- bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - This is a ridiculous argument, Bill. All of us depend on (or feel comfortable with) behavior that is not defined anywhere. Such behavior exists everywhere. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 9:33: 4 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 E237615805 for ; Tue, 30 Nov 1999 09:32:56 -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 SAA09105 for ; Tue, 30 Nov 1999 18:32:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71405 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:32:55 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BCB0615805 for ; Tue, 30 Nov 1999 09:32:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA25846; Tue, 30 Nov 1999 09:32:39 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 09:32:39 -0800 (PST) From: Matthew Dillon Message-Id: <199911301732.JAA25846@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Mmmm... that's not exactly what I'm worried about. I'm thinking of :applications which use threads to handle both i/o and cpu-bound :tasks. Our scheduler raises the i/o-bound tasks priority and lowers :cpu-bound tasks priority. With a program using threads to do both, :the scheduler would end up treating the process as cpu-bound and :lower it's priority. : :Ok, maybe that's fault of the application design, but still... :-) : :Processes with enough i/o-bound tasks to actually use up all quanta :before running out of threads will suffer from a similar fate. : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com :dcs@freebsd.org I don't think you have anything to worry about. A thread is going to go to sleep if it has nothing to do even if all the I/O is asynchronous (i.e. thread is mixing cpu and I/O bound elements). It isn't the I/O that raises the priority, it is the act of the process going to sleep that raises the priority. The basic characteristics of a program will not change whether it is threaded or not, because the program is still doing essentially the same task as it was before (just a little more efficiently). So if an unthreaded program tended to use 10% of the cpu before the same program threaded will also tend to use 10% of the cpu. You will wind up with something relatively close to what you had before in regards to the scheduling. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 9:35:13 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 4A24414DF3 for ; Tue, 30 Nov 1999 09:35:08 -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 SAA09133 for ; Tue, 30 Nov 1999 18:35:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71430 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:35:07 +0100 (MET) Received: from poboxer.pobox.com (ferg5200-1-3.cpinternet.com [208.149.16.3]) by hub.freebsd.org (Postfix) with ESMTP id 714F314DEC for ; Tue, 30 Nov 1999 09:34:56 -0800 (PST) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id LAA00420; Tue, 30 Nov 1999 11:34:48 -0600 (CST) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 30 Nov 1999 11:34:47 -0600 (CST) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: pulsifer@mediaone.net Cc: freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14404.1860.533508.695941@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoth Allen Pulsifer on Tue, 30 November: : : The purpose of threads is to provide a more efficient method : of multitasking. Threads can't do anything that asynchronous I/O can't do for you better, in terms of throughput efficiency -- indeed, until threads execute in parallel, the distinction is merely one of API. : Implementation details aside, it seems to me that one : of the major points Matt Dillion is looking for is : the ability for two threads, bound to the same : process, to run simultaneously on two different : CPU's. It would defeat the value of the effort from my POV. I'm not an active contributor to this effort, but as for myself, the value of the effort lies in SMP performance portability, i.e. the ability to write scalable thread code that runs at throughput proportionate to hardware capability on a variety of systems, such as Solaris, Linux, IRIX, and FreeBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 9:45: 1 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 9BFFF15981 for ; Tue, 30 Nov 1999 09:44: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 SAA09274 for ; Tue, 30 Nov 1999 18:44:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA71530 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 18:44:51 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 4273C1598E for ; Tue, 30 Nov 1999 09:43:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA04419; Tue, 30 Nov 1999 12:36:29 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA93794; Tue, 30 Nov 1999 12:38:52 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <38440BAB.E547CA61@vigrid.com> Date: Tue, 30 Nov 1999 12:38:51 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel M. Eischen" wrote: > > Julian Elischer wrote: > > > Yes, I understood them just fine :) I'm still not sold on the new > > > syscall gate and IOCB, because I think we have to make at least one > > > system call when threads are switched or resumed. > > > > > > > I'm not completely sold on them either. > > I just have a gut feeling on it based on doing this for 25 years. > > Well let's see if we can make them work, now that we know more > of the issues. > > One potential problem I see with placing the IOCBs at a fixed location > in the calling threads stack is that you then are tied to having > to find TSD for every system call. I say TSD, but really mean > you have to go through the same hoops as getting TSD. We don't > know how fast this is going to be for i386. > > I think if we allocate the IOCB from the stack at the time > of the system call, it will be faster. If the thread blocks, > then kernel can provide enough information so that the UTS > upcall can find the IOCB, set the IOCBptr in the current > thread, mark the thread as blocked, etc. Aside from the above issue, the other issue I had with Julians async-call gates and having the kernel complete the KSEs is that the UTS needs an "interrupt" type mechanism in order to check for threads in wait/timeout conditions and to preempt running threads that have exceeded their quantum. My argument was that we need to perform at least one system call for each thread switch in order to achieve this, so why have an async-call gate if we have to reenter the kernel anyways? I think we can fulfill our needs with a fixed interval timing mechanism, and to properly account for time spent in the system on a per-KSE basis. So, FWIW, I am prepared to sign up to Julians async call gate proposal. I think we can perform thread switches totally in userland without any assistance from the kernel. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10: 0:57 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 133F01596E for ; Tue, 30 Nov 1999 10:00:53 -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 TAA09479 for ; Tue, 30 Nov 1999 19:00:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71641 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:00:51 +0100 (MET) Received: from msn166-109.med.und.nodak.edu (msn166-109.med.und.NoDak.edu [134.129.166.109]) by hub.freebsd.org (Postfix) with ESMTP id 0002F1596E for ; Tue, 30 Nov 1999 10:00:42 -0800 (PST) (envelope-from bpederson@geocities.com) Received: from accord.med.und.nodak.edu ([134.129.166.13] helo=geocities.com) by msn166-109.med.und.nodak.edu with esmtp (Exim 3.03 #1) id 11srZx-000PC4-00 for arch@freebsd.org; Tue, 30 Nov 1999 12:00:41 -0600 Message-ID: <384410A4.22DCF089@geocities.com> Date: Tue, 30 Nov 1999 12:00:04 -0600 From: Barry Pederson X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.csrc/sys/libkern arc4random.c src/sys/sys libkern.h References: <199911301720.JAA25777@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: > > :Depending on a behavior that isn't defined anywhere and doesn't > :always work falls in my definition of "negative clue". > : > :-- > :- bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - > > This is a ridiculous argument, Bill. All of us depend on (or feel > comfortable with) behavior that is not defined anywhere. Such behavior > exists everywhere. Sorry, but I have to agree with Bill on this...depending on undefined behavior in a system is just plain bad practice. You're gonna get burned eventually when someone implements a similar system but doesn't necessarily exactly copy all the undefined behaviors. Barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:15:10 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 2FD5815985 for ; Tue, 30 Nov 1999 10:15:02 -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 TAA09653 for ; Tue, 30 Nov 1999 19:14:59 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71755 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:14:58 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 560B11599A for ; Tue, 30 Nov 1999 10:14:50 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (dcs@p13-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.110]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id DAA03928; Wed, 1 Dec 1999 03:14:43 +0900 (JST) Message-ID: <38441379.D8CD6CCD@newsguy.com> Date: Wed, 01 Dec 1999 03:12:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@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: > > I don't think you have anything to worry about. A thread is going to go > to sleep if it has nothing to do even if all the I/O is asynchronous > (i.e. thread is mixing cpu and I/O bound elements). It isn't the I/O > that raises the priority, it is the act of the process going to sleep > that raises the priority. Perhaps there is a misunderstanding here. It is my impression that the scheduler will not see these threads going to sleep, it will only see a process use all it's quanta instead of going to sleep, because the process always get control back from the kernel whenever a blocking operation happens, and in the end, a cpu-bound thread will finish up the quanta the i/o-bound threads didn't. That's one thing people have been asking for, that the kernel never puts a process to sleep but instead return control to the process as long as it has quanta remaining. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:20:33 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 6B97D159A1 for ; Tue, 30 Nov 1999 10:20:14 -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 TAA09712 for ; Tue, 30 Nov 1999 19:20:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71793 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:20:13 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 17890159A1 for ; Tue, 30 Nov 1999 10:19:50 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA22785; Tue, 30 Nov 1999 11:19:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26598; Tue, 30 Nov 1999 11:19:28 -0700 Date: Tue, 30 Nov 1999 11:19:28 -0700 Message-Id: <199911301819.LAA26598@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: "Daniel C. Sobral" , freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler In-Reply-To: <199911301732.JAA25846@apollo.backplane.com> References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Mmmm... that's not exactly what I'm worried about. I'm thinking of > :applications which use threads to handle both i/o and cpu-bound > :tasks. Our scheduler raises the i/o-bound tasks priority and lowers > :cpu-bound tasks priority. With a program using threads to do both, > :the scheduler would end up treating the process as cpu-bound and > :lower it's priority. > : > :Ok, maybe that's fault of the application design, but still... :-) > : > :Processes with enough i/o-bound tasks to actually use up all quanta > :before running out of threads will suffer from a similar fate. > : > :-- > :Daniel C. Sobral (8-DCS) > :dcs@newsguy.com > :dcs@freebsd.org > > I don't think you have anything to worry about. A thread is going to go > to sleep if it has nothing to do even if all the I/O is asynchronous > (i.e. thread is mixing cpu and I/O bound elements). It isn't the I/O > that raises the priority, it is the act of the process going to sleep > that raises the priority. > > The basic characteristics of a program will not change whether it is > threaded or not, because the program is still doing essentially the > same task as it was before (just a little more efficiently). So if > an unthreaded program tended to use 10% of the cpu before the same > program threaded will also tend to use 10% of the cpu. Actually, not necessarily. It may use up 'more' CPU since it can now more 'effeciently' use all of the available quantum, instead of idling. However, on a loaded (non-idle) system assuming the scheduler does a good job of things, the net result should be similar. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:20:57 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 64F7514CD2 for ; Tue, 30 Nov 1999 10:20:54 -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 TAA09732 for ; Tue, 30 Nov 1999 19:20:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71820 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:20:53 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 7697B14CD2 for ; Tue, 30 Nov 1999 10:20:44 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA22807; Tue, 30 Nov 1999 11:20:37 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA26607; Tue, 30 Nov 1999 11:20:36 -0700 Date: Tue, 30 Nov 1999 11:20:36 -0700 Message-Id: <199911301820.LAA26607@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: alk@pobox.com Cc: pulsifer@mediaone.net, freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? In-Reply-To: <14404.1860.533508.695941@avalon.east> References: <14404.1860.533508.695941@avalon.east> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : The purpose of threads is to provide a more efficient method > : of multitasking. > > Threads can't do anything that asynchronous I/O can't do for you > better, in terms of throughput efficiency -- indeed, until > threads execute in parallel, the distinction is merely one of API. Assuming that I/O is the bottleneck, yes. But, that is but one of the many advantages of threads, which include better algorithms, more effecient use of resources (quantum, memory), etc.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:24:54 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 219D4159A9 for ; Tue, 30 Nov 1999 10:24:46 -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 TAA09779 for ; Tue, 30 Nov 1999 19:24:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71864 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:24:45 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 50093159A9 for ; Tue, 30 Nov 1999 10:24:29 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id MAA14026; Tue, 30 Nov 1999 12:24:23 -0600 (CST) (envelope-from dick) Date: Tue, 30 Nov 1999 12:24:23 -0600 From: "Richard Seaman, Jr." To: "Daniel M. Eischen" Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <19991130122423.N29767@tar.com> References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <38440BAB.E547CA61@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Nov 30, 1999 at 12:38:51PM -0500, Daniel M. Eischen wrote: > I think we can perform thread switches totally in > userland without any assistance from the kernel. This would be a big performance plus. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:30:41 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 87360159B1 for ; Tue, 30 Nov 1999 10:29:58 -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 TAA09846 for ; Tue, 30 Nov 1999 19:29:57 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71924 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:29:57 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CAA44159B1 for ; Tue, 30 Nov 1999 10:29:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA26530; Tue, 30 Nov 1999 10:29:42 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 10:29:42 -0800 (PST) From: Matthew Dillon Message-Id: <199911301829.KAA26530@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@apollo.backplane.com> <38441379.D8CD6CCD@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Perhaps there is a misunderstanding here. It is my impression that :the scheduler will not see these threads going to sleep, it will :only see a process use all it's quanta instead of going to sleep, :because the process always get control back from the kernel whenever :a blocking operation happens, and in the end, a cpu-bound thread :will finish up the quanta the i/o-bound threads didn't. : :That's one thing people have been asking for, that the kernel never :puts a process to sleep but instead return control to the process as :long as it has quanta remaining. : :-- :Daniel C. Sobral (8-DCS) You are assuming that the application somehow requires more cpu in a threaded environment verses an unthreaded environment. I am saying that when you finish up tallying all the cpu the application uses, it is going to be nearly the same whether the application serializes the system calls (i.e. unthreaded) or doesn't serialize the system calls. From the point of view of the UNIX scheduler. Remember that the kernel already heavily caches and buffers I/O -- for example, writes to a TCP socket, or reads from a TCP socket after data has already been received to it. Most I/O related system calls either return immediately with the data you want, or the blocking case is one that even a threaded application may eventually have to wait for an event on (i.e. it may block, just not necessarily at the time the I/O is issued). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:31:59 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 42110159C1 for ; Tue, 30 Nov 1999 10:31:54 -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 TAA09871 for ; Tue, 30 Nov 1999 19:31:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA71957 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:31:50 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 66C69159CC for ; Tue, 30 Nov 1999 10:31:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA26563; Tue, 30 Nov 1999 10:31:37 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 10:31:37 -0800 (PST) From: Matthew Dillon Message-Id: <199911301831.KAA26563@apollo.backplane.com> To: Barry Pederson Cc: arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.csrc/sys/libkern arc4random.c src/sys/sys libkern.h References: <199911301720.JAA25777@apollo.backplane.com> <384410A4.22DCF089@geocities.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :Sorry, but I have to agree with Bill on this...depending on undefined :behavior in a system is just plain bad practice. You're gonna get :burned eventually when someone implements a similar system but doesn't :necessarily exactly copy all the undefined behaviors. : : Barry This is ridiculous. We aren't talking about people writing scripts here. We are talking about human nature. Human beings are not computers and expecting them to act like a computer in their everyday sysadmining is just plain ridiculous. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 10:42: 3 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 AB0D414D71 for ; Tue, 30 Nov 1999 10:42:01 -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 TAA09959 for ; Tue, 30 Nov 1999 19:42:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA72016 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:41:59 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F1AFC14D71 for ; Tue, 30 Nov 1999 10:41:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA26600; Tue, 30 Nov 1999 10:41:51 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 10:41:51 -0800 (PST) From: Matthew Dillon Message-Id: <199911301841.KAA26600@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think implementing a threading mechanism in the kernel is going to be a whole lot easier then implementing async call gates. In fact, the whole KSE mechanism is going to be easier to implement if they are integrated into a native kernel-based threading mechanism. If you *don't* do that, you *still* have to implement 80% of a kernel-based threading mechanism simply to be able to manage the KSE's, and so far I've heard half a dozen other special cases come up as being 'absolutely necessary' to prevent screwups. Frankly, when people talk about upcalls, wiring user memory, and controlling blocked kernel-mode KSEs from a user program... it *scares* me. I can implement kernel KSE's with an integrated kernel thread mechanism in a week, but I'm not going to do it unless I have a reasonable assurance that I can commit it :-). Most of the ground work has already been accomplished -- it became easy to do the moment the kernel stack was moved out of the common VM share. If we did things this way, I guarentee you that implementing a UTS will become trivial, without *any* special cases. In fact, it could be done without any upcalls either. A simple event reporting mechanism and a management thread to handle the everyone-is-asleep case is all you need. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 11: 4:25 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 4EAE414F26 for ; Tue, 30 Nov 1999 11:04:20 -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 UAA10151 for ; Tue, 30 Nov 1999 20:04:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA72193 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 20:04:19 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 4F2C814DDE for ; Tue, 30 Nov 1999 11:04:08 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id OAA18280; Tue, 30 Nov 1999 14:03:45 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Tue, 30 Nov 1999 14:03:45 -0500 (EST) From: Chuck Robey To: Allen Pulsifer Cc: freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? In-Reply-To: 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 Tue, 30 Nov 1999, Allen Pulsifer wrote: > Please forgive me for sticking my foot into this conversation. > I'm new to FreeBSD and have only been following this conversation > for a week. I don't pretend to know a lot of the theory, or even > how threads and SMP are currently implremented in FreeBSD. You can actually catch up, the discussion is in the archives, and it's very readable. It gets ahead of me sometimes, and I do that. > The purpose of threads is to provide a more efficient method > of multitasking. The goals of threads are to: > 1) minimize the amount of memory that each thread uses, > so that many (thousands?) of threads can be created; I don't think saving of memory as such is important. We need, however, to stay within shouting distance of other threads implementations (and POSIX's idea of threads) so this goal of yours is accomplished, but it's not a main goal of our effort. The fact of it being a shared memory area gives that as a side effect. Some other goals, like efficiency, motivate a shared memory area, which in turn give lower memory usage, but that's a result, not a goal. > Other items > may be shared or not shared depending on what > you are trying to accomplish. A lot of the decisions > are tradeoffs between functionality and efficiency. > For example, it would seem desirable to make the > unshared structures as small as possible, to > minimize memory use; No, it's *not* to minimize memory use. Considerations here are that increasing the amount of thread data may possible have some effect on thread context switching, and the complications of that. Memory usage is not really at all a factor. however, that may sacrifice > functionality. I am not familiar with all of the > structures involved, but maybe someone would make > a list: what structures must absolutely be > unshared, and what structures can optionally be made > unique, and what features or functionality are gained > by making them unique? A list like this would assist > in the tradeoff analysis and decision making. This isn't possible until the general strategy for implementing the threads is decided upon. The tradeoffs being considered are increased functionality against increased complexity. We want every possible feature, but if we make it too complicated, it will never be accomplished, or it will never really work bug-free. Thus we are exploring strategies to limit the complexity while increasing the things we do want, like reliability, efficiency (in use of resources), and simplicity. > Implementation details aside, it seems to me that one > of the major points Matt Dillion is looking for is > the ability for two threads, bound to the same > process, to run simultaneously on two different > CPU's. This seems to be a very desirable goal, > however, the question seems to be, what is the cost > of implementing this in terms of complexity and level > of effort? It's a key goal, and not even really subject to any argument so far. We already *do* have user-mode threading, that doesn't give this feature, and it has very obvious and regreattable consequences to efficient use of resources. Very definitely, we want N threads to be able to make use of M processors. This is extremely well documented in the mail archives. > In addition, if it is guaranteed that a thread will > not surrender the CPU to another thread in its same > process except at certain well defined times > (a voluntary surrender, a system call, a signal) > does that simplify user programming even more? Then it would no longer even fit any current thread standard, and really be close to useless for the majority of threaded programs. > Do these gains in simplicity make it worthwile > not implementing what might otherwise be a > powerful feature? I hate to say it, but it's a large step down in usefullness of our current user-mode threads, which are in themselves now considered less than optimally useful, and certainly less than optimally efficient (else this discussion would not be taking place). ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 11:14:19 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 0FC5C14D2A for ; Tue, 30 Nov 1999 11:14:13 -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 UAA10213 for ; Tue, 30 Nov 1999 20:14:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA72246 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 20:14:11 +0100 (MET) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E5146159D8; Tue, 30 Nov 1999 11:13:49 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA91222; Tue, 30 Nov 1999 11:13:42 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Bill Fumerola Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Tue, 30 Nov 1999 09:45:14 EST." Date: Tue, 30 Nov 1999 11:13:42 -0800 Message-ID: <91218.943989222@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Depending on a behavior that isn't defined anywhere and doesn't > always work falls in my definition of "negative clue". You're too newly-minted an admin to have an informed opinion about this, I hate to say. People who've been doing Unix since the 70's have different definitions of "defined" since anything you use for over 10 years becomes "defined" whether it's written down anywhere or not, and there are thousands of examples of this around. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 11:15:34 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 9729814EA5 for ; Tue, 30 Nov 1999 11:15:29 -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 UAA10242 for ; Tue, 30 Nov 1999 20:15:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA72280 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 20:15:28 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id E6611159D8 for ; Tue, 30 Nov 1999 11:14:58 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (dcs@p13-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.110]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id EAA22234; Wed, 1 Dec 1999 04:14:54 +0900 (JST) Message-ID: <38442193.931386B6@newsguy.com> Date: Wed, 01 Dec 1999 04:12:19 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@apollo.backplane.com> <38441379.D8CD6CCD@newsguy.com> <199911301829.KAA26530@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: > > You are assuming that the application somehow requires more cpu > in a threaded environment verses an unthreaded environment. I am saying > that when you finish up tallying all the cpu the application uses, it > is going to be nearly the same whether the application serializes the > system calls (i.e. unthreaded) or doesn't serialize the system calls. > From the point of view of the UNIX scheduler. No, not at all. For example think of an application with two processes: one does i/o on a tcp socket and the other number-crunches data. It gets converted to threads, so that it is now just one process. Whenever the process "blocks" in the kernel doing i/o, instead of being put to sleep control is returned to it, and it spends the rest of it's quanta doing number-crunching. The scheduler will not identify that process as one who does i/o. But... whatever. I'll just wait and see. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 11:36:25 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 0113914E88 for ; Tue, 30 Nov 1999 11:36:22 -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 UAA10460 for ; Tue, 30 Nov 1999 20:36:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA72481 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 20:36:18 +0100 (MET) Received: from houston.matchlogic.com (houston.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 2A73D14E88 for ; Tue, 30 Nov 1999 11:36:04 -0800 (PST) (envelope-from crandall@matchlogic.com) Received: by houston.matchlogic.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 Nov 1999 12:36:03 -0700 Message-ID: <64003B21ECCAD11185C500805F31EC0304622184@houston.matchlogic.com> From: Charles Randall To: Allen Pulsifer , freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? Date: Tue, 30 Nov 1999 12:35:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For a portable threading system like that, take a look at Ralf Engelschall's GNU Pth, http://www.gnu.org/software/pth/ Charles -----Original Message----- From: Allen Pulsifer [mailto:pulsifer@mediaone.net] Sent: Tuesday, November 30, 1999 9:55 AM To: freebsd-arch@freebsd.org Subject: RE: Revisitted.. Threads goals.? ... For example, if it is guaranteed that two threads bound to a process cannot be executing simultaneously, does that simplify user programming? In addition, if it is guaranteed that a thread will not surrender the CPU to another thread in its same process except at certain well defined times (a voluntary surrender, a system call, a signal) does that simplify user programming even more? Do these gains in simplicity make it worthwile not implementing what might otherwise be a powerful feature? ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 11:51:59 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 7605B14D0F for ; Tue, 30 Nov 1999 11:51:55 -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 UAA10663 for ; Tue, 30 Nov 1999 20:51:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA72639 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 20:51:52 +0100 (MET) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 76B74159FB; Tue, 30 Nov 1999 11:51:25 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id 75EA21C66; Tue, 30 Nov 1999 13:52:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id 72184381B; Tue, 30 Nov 1999 13:52:28 -0500 (EST) Date: Tue, 30 Nov 1999 13:52:28 -0500 (EST) From: Bill Fumerola To: "Jordan K. Hubbard" Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <91218.943989222@zippy.cdrom.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 Tue, 30 Nov 1999, Jordan K. Hubbard wrote: > You're too newly-minted an admin to have an informed opinion about > this, I hate to say. People who've been doing Unix since the 70's > have different definitions of "defined" since anything you use for > over 10 years becomes "defined" whether it's written down anywhere or > not, and there are thousands of examples of this around. There's nothing like the "I'm older and have been doing this longer." to explain something. I still say that there are too many external factors in the old linear system to depend on getting a certain pid. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 12:54:10 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 0DA7A14E0A for ; Tue, 30 Nov 1999 12:54:07 -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 VAA11276 for ; Tue, 30 Nov 1999 21:54:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA72934 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 21:54:02 +0100 (MET) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 397B114E0A for ; Tue, 30 Nov 1999 12:53:49 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id NAA21405; Tue, 30 Nov 1999 13:53:26 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp02.primenet.com, id smtpdAAARga4QP; Tue Nov 30 13:53:15 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA05793; Tue, 30 Nov 1999 13:53:09 -0700 (MST) From: Terry Lambert Message-Id: <199911302053.NAA05793@usr09.primenet.com> Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 30 Nov 1999 20:53:09 +0000 (GMT) Cc: bpederson@geocities.com, arch@freebsd.org In-Reply-To: <199911301831.KAA26563@apollo.backplane.com> from "Matthew Dillon" at Nov 30, 99 10:31:37 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Sorry, but I have to agree with Bill on this...depending on undefined > :behavior in a system is just plain bad practice. You're gonna get > :burned eventually when someone implements a similar system but doesn't > :necessarily exactly copy all the undefined behaviors. > > This is ridiculous. We aren't talking about people writing scripts > here. We are talking about human nature. Human beings are not > computers and expecting them to act like a computer in their everyday > sysadmining is just plain ridiculous. Matt's right. Expecting humans to exhibit this level of competence on average is unreasonable. Instead, you should hire competent system admins, and expect that average humans will be able to obtain jobs in the food service industry. Someone has to ask good sysadmins whether or not they want fries withtheir McMeals. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 12:55:18 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 7709715A1A for ; Tue, 30 Nov 1999 12:55:15 -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 VAA11307 for ; Tue, 30 Nov 1999 21:55:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA72969 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 21:55:14 +0100 (MET) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id BF09F15A1A; Tue, 30 Nov 1999 12:54:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id NAA18044; Tue, 30 Nov 1999 13:54:10 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpdAAAz1aimJ; Tue Nov 30 13:54:07 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id NAA05867; Tue, 30 Nov 1999 13:54:41 -0700 (MST) From: Terry Lambert Message-Id: <199911302054.NAA05867@usr09.primenet.com> Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c To: billf@chc-chimes.com (Bill Fumerola) Date: Tue, 30 Nov 1999 20:54:41 +0000 (GMT) Cc: jkh@zippy.cdrom.com, kris@hub.freebsd.org, dillon@apollo.backplane.com, dan@freebsd.org, arch@freebsd.org, audit@freebsd.org In-Reply-To: from "Bill Fumerola" at Nov 30, 99 01:52:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You're too newly-minted an admin to have an informed opinion about > > this, I hate to say. People who've been doing Unix since the 70's > > have different definitions of "defined" since anything you use for > > over 10 years becomes "defined" whether it's written down anywhere or > > not, and there are thousands of examples of this around. > > There's nothing like the "I'm older and have been doing this > longer." to explain something. > > I still say that there are too many external factors in the old > linear system to depend on getting a certain pid. SMP, anyone? You are supposed to use the variable containing the child process ID in your scripts, anyway. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 12:58:54 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 6BC2D15A2B for ; Tue, 30 Nov 1999 12:58:51 -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 VAA11356 for ; Tue, 30 Nov 1999 21:58:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA73002 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 21:58:50 +0100 (MET) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id B528F15A2B for ; Tue, 30 Nov 1999 12:58:41 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C4B3E1C67; Tue, 30 Nov 1999 14:59:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id AF104381B; Tue, 30 Nov 1999 14:59:44 -0500 (EST) Date: Tue, 30 Nov 1999 14:59:44 -0500 (EST) From: Bill Fumerola To: Terry Lambert Cc: Matthew Dillon , bpederson@geocities.com, arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern In-Reply-To: <199911302053.NAA05793@usr09.primenet.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 Tue, 30 Nov 1999, Terry Lambert wrote: > > This is ridiculous. We aren't talking about people writing scripts > > here. We are talking about human nature. Human beings are not > > computers and expecting them to act like a computer in their everyday > > sysadmining is just plain ridiculous. > > Matt's right. He's right about human nature, though I don't see how the above or below prove that expecting linear PIDs is a good practice. > Expecting humans to exhibit this level of competence on average > is unreasonable. > > Instead, you should hire competent system admins, and expect that > average humans will be able to obtain jobs in the food service > industry. Someone has to ask good sysadmins whether or not they > want fries withtheir McMeals. -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 14:19:49 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 2CDB214C97 for ; Tue, 30 Nov 1999 14:19:46 -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 XAA12019 for ; Tue, 30 Nov 1999 23:19:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA73297 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 23:19:44 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 5A63814C97; Tue, 30 Nov 1999 14:19:30 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40330>; Wed, 1 Dec 1999 09:12:02 +1100 Content-return: prohibited Date: Wed, 1 Dec 1999 09:19:18 +1100 From: Peter Jeremy Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: <89015.943945313@zippy.cdrom.com> To: arch@freebsd.org, audit@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec1.091202est.40330@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <89015.943945313@zippy.cdrom.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-30 18:01:53 +1100, Jordan K. Hubbard wrote: >> This would fall under my preferred policy, which you didn't quote, namely >> "turn on everything which doesn't have a negative impact, and providing > >Not being able to predict pids (for useful purposes) would fall under >the definition of "negative impact" for a number of admins. I agree. Digital UNIX uses something like random PID generation and I find it a PITA. Sequential PID allocation makes it much easier to get a feeling for what is going on (and in what order). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 14:27:42 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 E414F14CFF for ; Tue, 30 Nov 1999 14:27:39 -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 XAA12089 for ; Tue, 30 Nov 1999 23:27:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA73348 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 23:27:38 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 96D7F14CFF for ; Tue, 30 Nov 1999 14:27:22 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 37843 invoked by uid 1001); 30 Nov 1999 22:25:55 -0000 Date: Tue, 30 Nov 1999 14:25:55 -0800 From: Jason Evans To: Matthew Dillon Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991130142555.F301@sturm.canonware.com> References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from dillon@apollo.backplane.com on Sat, Nov 27, 1999 at 07:38:52PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 27, 1999 at 07:38:52PM -0800, Matthew Dillon wrote: > :Until reading about DEC's threading efforts > :(http://www.digital.com/info/DTJF03/DTJF03SC.TXT) a few days ago, I would > :have agreed with you. However, that paper makes some very valid arguments > :for needing multiple scheduling queues. The paper is very worthwhile > :reading. > : > :Jason > > hmm. A very interesting article. They could well be correct - certainly > a single scheduling queue would become a problem if you have many > processors. I don't think there would be much contention with 4-8 cpu's, > at least not if we limit the lock to *just* the operation surrounding > the addition and removal of the KSE (using Julian's terminology) from > the queue. Also, this contention would *not* occur during a context > switch, only when a task is scheduled and descheduled. It seems to me that there would be some significant negative impacts due to cache sloshing, since all CPUs would need to modify the same scheduling queue often enough for it to be a big deal. I agree that the lock contention would be insignificant, but the caching issues seem real. Maybe I don't completely understand what you're proposing. > Another possible solution to the single-queue case is to not lock the > queue for sleep/wakeup operations but to instead shared-lock the > surrounding task(s). This would allow multiple cpu's to add and remove > tasks from different parts of a single queue simultaniously. I've > never done this myself -- it's never seemed worthwhile. Hmm, this idea could have some merit. We should keep it in mind. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 14:43:20 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 421FB14C99 for ; Tue, 30 Nov 1999 14:43:10 -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 XAA12227 for ; Tue, 30 Nov 1999 23:43:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA73487 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 23:43:09 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 132B514C99 for ; Tue, 30 Nov 1999 14:43:01 -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 OAA99213; Tue, 30 Nov 1999 14:43:00 -0800 (PST) Date: Tue, 30 Nov 1999 14:43:00 -0800 (PST) From: Julian Elischer To: Jason Evans Cc: Matthew Dillon , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <19991130142555.F301@sturm.canonware.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 Tue, 30 Nov 1999, Jason Evans wrote: > > tasks from different parts of a single queue simultaniously. I've > > never done this myself -- it's never seemed worthwhile. > > Hmm, this idea could have some merit. We should keep it in mind. multiple queues with load balancing.... (i.e subprocesses) :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 17:32:45 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 E4A3D15A23 for ; Tue, 30 Nov 1999 17:32:43 -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 CAA16638 for ; Wed, 1 Dec 1999 02:32:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA74481 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 02:32:41 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 9DA4815A23 for ; Tue, 30 Nov 1999 17:32:32 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 41291 invoked by uid 1001); 1 Dec 1999 01:31:04 -0000 Date: Tue, 30 Nov 1999 17:31:04 -0800 From: Jason Evans To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Revisitted.. Threads goals.? Message-ID: <19991130173104.K301@sturm.canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from julian@whistle.com on Mon, Nov 29, 1999 at 10:45:28PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 29, 1999 at 10:45:28PM -0800, Julian Elischer wrote: > > I think this is a good time for us to re-examine some of the things that > we decided were goals. > > I have somme comments I'd like to make AT THE END, but after the general > neuron frying of the last week or so it might be a good idea to look at > these again and see if any of them have changed in light of the > discussion. I have difficulty in seeing this list as exhaustive or > correct. We need someone who is very into threads to contribute. > Jason? What do yuo see as YOUR goals? Whew, I just now caught up with the volumes of email that you guys generated while I was eating turkey 1000 miles from home. =) Thus the delayed response. Right now, I'm concerning myself with last minute details for 4.0. Most of the discussion in -arch has concerned what I hope we can start tackling after 4.0 is released. Pre-4.0 goals: I sent email a week ago with a list of PRs that I intend to go through. A couple of additional PRs have been brought to my attention since then. I've gathered sufficient documentation to go through our current threads implementation and verify our compliance/noncompliance with the POSIX spec. This is a longer-term goal, but I want to put together a relatively complete compliance/correctness test suite, which should save us time in the end. In addition to the general cleanup that needs to happen, Daniel has some patches I'm sitting on (I'll look at them RSN, honest!) that will in all likelihood be committed this week. One goal that I did not list last week, but one that is important (first brought up by Peter, I think), is to make the LinuxThreads work done by Richard natively useable (i.e. not under Linux emulation). This is admittedly an interim solution, but it should be relatively easy to make work, and will be genuinely useful in a number of places. Post-4.0 goals: The discussion thus far in -arch has been great. I'm in general agreement with what Julian and Daniel have discussed. There are still a couple of details to work out, but I feel good about the direction the conversation has gone. Matthew has brought up some alternatives that in my mind still need to be discussed a bit. The lure of simplicity is great, but it isn't clear to me that Matthew's proposal meets all of our goals. Then again, I can't claim to understand the full scope of his proposal, whereas I've read the SA papers and have a good feel for that class of threads solution. One pragmatic issue that we need to discuss is how well we can develop the new threads package in an evolutionary fashion. There are a number of kernel modifications (at least scheduler and upcall mechanisms, possibly a new call gate), as well as the need for a significantly different UTS from what we have now. Perhaps we can discuss our plan of attack in some detail as soon as we're all basically happy with the planned final solution. Like I said before, there are a couple of unresolved design issues in my mind, so it probably makes sense to wrap those up first. Okay, time to catch a train. More at 11. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 18:18:45 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 5A66114CD1 for ; Tue, 30 Nov 1999 18:18: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 DAA16944 for ; Wed, 1 Dec 1999 03:18:41 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA74647 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 03:18:41 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C5F0214CD1; Tue, 30 Nov 1999 18:18:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA28858; Tue, 30 Nov 1999 18:18:29 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 18:18:29 -0800 (PST) From: Matthew Dillon Message-Id: <199912010218.SAA28858@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Bill Fumerola , Kris Kennaway , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h References: <91218.943989222@zippy.cdrom.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Depending on a behavior that isn't defined anywhere and doesn't :> always work falls in my definition of "negative clue". : :You're too newly-minted an admin to have an informed opinion about :this, I hate to say. People who've been doing Unix since the 70's Mm. Unless you know the guy from grade school, you can hardly make that sort of statement. I know kids 15 years my junior who are as good programmers as I am. Well, ok, I know *one* kid. Well, ok, he *IS* a little crazy. Mmm. A lot crazy. Would you believe .... ? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 18:24:55 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 430C714CD1 for ; Tue, 30 Nov 1999 18:24: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 DAA16997 for ; Wed, 1 Dec 1999 03:24:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA74686 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 03:24:52 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D37414CD1 for ; Tue, 30 Nov 1999 18:24:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA28925; Tue, 30 Nov 1999 18:24:46 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 18:24:46 -0800 (PST) From: Matthew Dillon Message-Id: <199912010224.SAA28925@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-arch@freebsd.org Subject: Re: Threads and the scheduler References: <3842DBB5.8AFC9B6@newsguy.com> <199911292022.MAA08694@apollo.backplane.com> <3843D43E.4F40A642@newsguy.com> <199911301732.JAA25846@apollo.backplane.com> <38441379.D8CD6CCD@newsguy.com> <199911301829.KAA26530@apollo.backplane.com> <38442193.931386B6@newsguy.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> that when you finish up tallying all the cpu the application uses, it :> is going to be nearly the same whether the application serializes the :> system calls (i.e. unthreaded) or doesn't serialize the system calls. :> From the point of view of the UNIX scheduler. : :No, not at all. For example think of an application with two :processes: one does i/o on a tcp socket and the other :number-crunches data. It gets converted to threads, so that it is :now just one process. Whenever the process "blocks" in the kernel :doing i/o, instead of being put to sleep control is returned to it, :and it spends the rest of it's quanta doing number-crunching. I believe I mentioned the kernel caching issue with I/O. Just because you are making a syscall does *not* mean you are getting the benefit of I/O scheduling and does *not* mean that you will block, only that you might block. Over the years kernels have been heavily optimized to disassociate I/O from the process requesting the I/O. For example, FreeBSD has TCP buffers in the kernel and issues read-ahead on its disks, over NFS, and so forth. If the kernels were not so heavily optimized to disassociate I/O then you would be right. But since they are, I do not think you will see the difference in effect that you expect. :The scheduler will not identify that process as one who does i/o. : :But... whatever. I'll just wait and see. : :-- :Daniel C. Sobral (8-DCS) -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 19:46: 9 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 6537D15A6A for ; Tue, 30 Nov 1999 19:44:58 -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 EAA17920 for ; Wed, 1 Dec 1999 04:44:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA74954 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 04:44:48 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id B386214D6A; Tue, 30 Nov 1999 19:44:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A3E0A1CD7F7; Tue, 30 Nov 1999 19:44:38 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 30 Nov 1999 19:44:38 -0800 (PST) From: Kris Kennaway To: "Jordan K. Hubbard" Cc: Matthew Dillon , arch@freebsd.org, audit@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <89015.943945313@zippy.cdrom.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 Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > > This would fall under my preferred policy, which you didn't quote, namely > > "turn on everything which doesn't have a negative impact, and providing > > Not being able to predict pids (for useful purposes) would fall under > the definition of "negative impact" for a number of admins. Well, I think it would be quite useful by default because of the boost it gives for badly written applications, but I'm certainly not going to go to war over it. I'm content to leave it for the viking contingent to liberate when they sail in on their longboats one cold danish morn :-) Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 30 21:34: 3 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 171AE14C4E for ; Tue, 30 Nov 1999 21:33:58 -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 GAA18638 for ; Wed, 1 Dec 1999 06:33:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA75207 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 06:33:52 +0100 (MET) Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 6EC7E14C4E; Tue, 30 Nov 1999 21:33:38 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA30992; Wed, 1 Dec 1999 00:33:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <91218.943989222@zippy.cdrom.com> References: <91218.943989222@zippy.cdrom.com> Date: Wed, 1 Dec 1999 00:39:02 -0500 To: "Jordan K. Hubbard" , Bill Fumerola From: Garance A Drosihn Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h Cc: Kris Kennaway , Matthew Dillon , Dan Moschuk , arch@freebsd.org, audit@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:13 AM -0800 11/30/99, Jordan K. Hubbard wrote: > > Depending on a behavior that isn't defined anywhere and doesn't > > always work falls in my definition of "negative clue". > >You're too newly-minted an admin to have an informed opinion about >this, I hate to say. People who've been doing Unix since the 70's >have different definitions of "defined" since anything you use for >over 10 years becomes "defined" whether it's written down anywhere >or not, and there are thousands of examples of this around. Hmm. I think you're putting the emphasis on the wrong part of his sentence. I read it as: Writing something which *depends* on this behavior is a bad idea, because this behavior does not always occur. Ie, it is *already* true that you can't "depend" on it. And since the behavior isn't written down anywhere as part of any standard, someone who depends on this can't even complain when the behavior does not happen. At the same time, I think there's a difference between finding something "useful" (as I remember the original comment), and "*depending* on that behavior". Something which is true 95% of the time can be "mighty useful" at times, even if I wouldn't want write anything which "depends" on that behavior. Just out of curiosity, is there some way we can provide the "useful" part even if the PID's are randomly assigned? Ie, what exactly *is* useful about sequential PID's? My guess is just that you want a history of which processes started in which order (including processes which may not be around any longer, or which have been reparented). Perhaps we could have some other mechanism for that? Is there any other legit benefit to having consecutive PID's? I'm just wondering, because that's the only benefit I've gotten from consecutive PID's. What I'm thinking is maybe just a wrapping buffer that keeps the last PID's which were assigned, and the PPID of the process that started each of those PID's. I imagine it'd be nice to also include process-creation timestamps, but that might chew up memory too fast. Would that provide the desired benefit, while still avoiding the security issues? [I'm sending this to both -arch and -audit, but I imagine the discussion should continue on just -arch...] --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 0:31:51 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 E6D0615A99 for ; Wed, 1 Dec 1999 00:31:49 -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 JAA20237 for ; Wed, 1 Dec 1999 09:31:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA75673 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 09:31:46 +0100 (MET) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9D5DB15A99; Wed, 1 Dec 1999 00:31:36 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11t5Ak-000DCd-00; Wed, 01 Dec 1999 10:31:34 +0200 From: Sheldon Hearn To: arch@freebsd.org Cc: "Jordan K. Hubbard" , Matthew Dillon , billf@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-reply-to: Your message of "Tue, 30 Nov 1999 19:44:38 PST." Date: Wed, 01 Dec 1999 10:31:34 +0200 Message-ID: <50754.944037094@axl.noc.iafrica.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > Not being able to predict pids (for useful purposes) would fall under > the definition of "negative impact" for a number of admins. Doesn't the new behaviour come with a sysctl knob (off by default) for controlling it? If so, what's all the fuss? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 3: 4:27 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 7A6E014F6A for ; Wed, 1 Dec 1999 03:04:24 -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 MAA22955 for ; Wed, 1 Dec 1999 12:04:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA76187 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 12:04:23 +0100 (MET) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id CDB8114F6A for ; Wed, 1 Dec 1999 03:04:13 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.040 #1) id 11t7YS-000EEM-00 for arch@FreeBSD.org; Wed, 01 Dec 1999 13:04:12 +0200 From: Sheldon Hearn To: arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern Date: Wed, 01 Dec 1999 13:04:12 +0200 Message-ID: <54705.944046252@axl.noc.iafrica.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Come on, people, this discussion isn't useful. Some people want randomized PID allocation, some people want linear PID allocation. There are understandable arguments for both if you can escape the clutches of bigotry for even the briefest of moments. The behaviour is to be controlled by a sysctl knob (kern.randompid), so let's give it a rest. Frob the knob to taste and move on, eh? :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 6:56:50 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 7BAD114D70 for ; Wed, 1 Dec 1999 06:56:47 -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 PAA27237 for ; Wed, 1 Dec 1999 15:56:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA77092 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 15:56:46 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 30D7514FEE for ; Wed, 1 Dec 1999 06:56:34 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id IAA17676 for arch@freebsd.org; Wed, 1 Dec 1999 08:56:33 -0600 (CST) (envelope-from dick) Date: Wed, 1 Dec 1999 08:56:33 -0600 From: "Richard Seaman, Jr." To: arch@freebsd.org Subject: Re: Revisitted.. Threads goals.? Message-ID: <19991201085633.Z29767@tar.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 29, 1999 at 10:45:28PM -0800, Julian Elischer wrote: > ---- possible userland implementation goals----- > > 1/ A libpthread that can be linked with libc. > > 2/ Libc needs to change so that library functions and system calls > used internal to the library do not use the externally visible > cancellable equivalents. I have some thoughts about what it takes to separate the uthread code from libc, which facitlitates point 1 above, and which also makes it easier to make libc thread safe for alternative pthreads implementations (eg. linuxthreads). Also, I have some thoughts about how to make libc (and/or libc_r) more thread safe. I'd be happy to jot these down over the next few days and send them out, if anyone is interested. But maybe someone has already done this or is in the process of doing it. If so, let me know and I won't duplicate the work. And, if you're not interested, don't say anything. I'll take no responses to this offer as "no interest". :) -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 7:18:44 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 A629C1518F for ; Wed, 1 Dec 1999 07:18:35 -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 QAA27554 for ; Wed, 1 Dec 1999 16:18:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77173 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 16:18:30 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 1092B14DB6 for ; Wed, 1 Dec 1999 07:17:40 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id IAA02844; Wed, 1 Dec 1999 08:16:58 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id IAA00286; Wed, 1 Dec 1999 08:16:57 -0700 Date: Wed, 1 Dec 1999 08:16:57 -0700 Message-Id: <199912011516.IAA00286@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Richard Seaman, Jr." Cc: arch@freebsd.org Subject: Re: Revisitted.. Threads goals.? In-Reply-To: <19991201085633.Z29767@tar.com> References: <19991201085633.Z29767@tar.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have some thoughts about what it takes to separate the uthread > code from libc, which facitlitates point 1 above, and which also > makes it easier to make libc thread safe for alternative pthreads > implementations (eg. linuxthreads). > > Also, I have some thoughts about how to make libc (and/or libc_r) > more thread safe. > > I'd be happy to jot these down over the next few days and send them > out, if anyone is interested. Count me as one who is interested. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 7:20:48 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 67EF514D0F for ; Wed, 1 Dec 1999 07:20:45 -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 QAA27595 for ; Wed, 1 Dec 1999 16:20:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77210 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 16:20:25 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8442314D0F; Wed, 1 Dec 1999 07:20:13 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CA04B1CA0; Wed, 1 Dec 1999 23:19:55 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Sheldon Hearn Cc: arch@freebsd.org, "Jordan K. Hubbard" , Matthew Dillon , billf@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: Message from Sheldon Hearn of "Wed, 01 Dec 1999 10:31:34 +0200." <50754.944037094@axl.noc.iafrica.com> Date: Wed, 01 Dec 1999 23:19:55 +0800 From: Peter Wemm Message-Id: <19991201151955.CA04B1CA0@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > > On Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > > > Not being able to predict pids (for useful purposes) would fall under > > the definition of "negative impact" for a number of admins. > > Doesn't the new behaviour come with a sysctl knob (off by default) for > controlling it? If so, what's all the fuss? At the risk of continuing the debate, what I would prefer would be a sysctl to define the range of a random increment to the nextpid, so there is an element of randomness still but you're going to get a steadily increasing set of pid's still. So, sysctl -w kern.randompid=1000 would get you an increment of between 1 and 1000 for each new process. You still end up with some randomness, but you still get increasing pids. The sysctl would accept a value between 0 (present behavior) and PID_MAX - 100. (I've added a wraparound and protected the pid's less than 100 like before). Using totally random pid's where the nextpid could be anywhere from 0 through 100000 means that the pidchecked code is getting very heavily excercised. That's a *lot* of list walking. Suggested patch at: http://overcee.netplex.com.au/~peter/randompid.diff A quick example where a process forks 5 children and prints the pid's: peter@t8000[11:16pm]-107> ./pid 0: child pid 242 1: child pid 243 2: child pid 244 3: child pid 245 4: child pid 246 root@t8000:[11:16pm]-100# sysctl -w kern.randompid=100 0 -> 100 peter@t8000[11:16pm]-108> ./pid 0: child pid 427 1: child pid 524 2: child pid 571 3: child pid 623 4: child pid 664 1000 or 10000 would be better for the more paranoid. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 7:25:27 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 A168615AF1 for ; Wed, 1 Dec 1999 07:25:07 -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 QAA27629 for ; Wed, 1 Dec 1999 16:25:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77241 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 16:25:06 +0100 (MET) Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 4718F14CFB; Wed, 1 Dec 1999 07:24:56 -0800 (PST) (envelope-from billf@chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id EB9E81C2B; Wed, 1 Dec 1999 09:25:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by jade.chc-chimes.com (Postfix) with ESMTP id E1D6E381B; Wed, 1 Dec 1999 09:25:49 -0500 (EST) Date: Wed, 1 Dec 1999 09:25:49 -0500 (EST) From: Bill Fumerola To: Peter Wemm Cc: Sheldon Hearn , arch@freebsd.org, "Jordan K. Hubbard" , Matthew Dillon , billf@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: <19991201151955.CA04B1CA0@overcee.netplex.com.au> 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, 1 Dec 1999, Peter Wemm wrote: > At the risk of continuing the debate, what I would prefer would be a sysctl > to define the range of a random increment to the nextpid, so there is an element > of randomness still but you're going to get a steadily increasing set of pid's > still. Why must you always come up with the really good solution? :-> -- - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 8:16:51 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 82CAC14D79 for ; Wed, 1 Dec 1999 08:16:48 -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 RAA28233 for ; Wed, 1 Dec 1999 17:16:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA77470 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 17:16:31 +0100 (MET) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 8E24E14D79 for ; Wed, 1 Dec 1999 08:16:24 -0800 (PST) (envelope-from rcarter@pinyon.org) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id JAA08517; Wed, 1 Dec 1999 09:15:15 -0700 (MST) Received: from ip-83-032.prc.primenet.com(207.218.83.32), claiming to be "pinyon.org" via SMTP by smtp04.primenet.com, id smtpdAAAAEaWdp; Wed Dec 1 09:15:07 1999 Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1]) by pinyon.org (Postfix) with ESMTP id 8239484; Wed, 1 Dec 1999 09:13:51 -0700 (MST) X-Mailer: exmh version 2.1.0 09/18/1999 To: Jason Evans Cc: Julian Elischer , freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Revisitted.. Threads goals.? In-Reply-To: Message from Jason Evans of "Tue, 30 Nov 1999 17:31:04 PST." <19991130173104.K301@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Dec 1999 09:13:51 -0700 From: "Russell L. Carter" Message-Id: <19991201161351.8239484@pinyon.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %On Mon, Nov 29, 1999 at 10:45:28PM -0800, Julian Elischer wrote: %> %> I think this is a good time for us to re-examine some of the things that %> we decided were goals. %> %> I have somme comments I'd like to make AT THE END, but after the general %> neuron frying of the last week or so it might be a good idea to look at %> these again and see if any of them have changed in light of the %> discussion. I have difficulty in seeing this list as exhaustive or %> correct. We need someone who is very into threads to contribute. %> Jason? What do yuo see as YOUR goals? % %One goal that I did not list last week, but one that is important (first %brought up by Peter, I think), is to make the LinuxThreads work done by %Richard natively useable (i.e. not under Linux emulation). This is %admittedly an interim solution, but it should be relatively easy to make %work, and will be genuinely useful in a number of places. It already works native now. I'm going to submit a libgcc_r addition to the port today. I build and run every ACE+TAO beta against it, as well as with libc_r threads. There are a couple of bugs left, but I've got to run the regression tests again today to get those characterized accurately, and that takes a while. At one point I had a pretty thorough performance test harness constructed using ACE for comparing libc_r and linuxthreads, it might be of use for the discussion of user vs. kernel context switching. Russell %Jason % % % % %To Unsubscribe: send mail to majordomo@FreeBSD.org %with "unsubscribe freebsd-arch" in the body of the message % To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 9:21:42 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 1FED315B2B for ; Wed, 1 Dec 1999 09:21:38 -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 SAA28894 for ; Wed, 1 Dec 1999 18:21:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA77700 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 18:21:35 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id E64D514C93 for ; Wed, 1 Dec 1999 09:18:28 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA03160 for ; Wed, 1 Dec 1999 12:10:16 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA95129 for ; Wed, 1 Dec 1999 12:12:40 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <38455708.F1DDF9DE@vigrid.com> Date: Wed, 01 Dec 1999 12:12:40 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: [Fwd: Threads stuff] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -arch should have been included "Daniel M. Eischen" wrote: > > Matthew Dillon wrote: > > > > I think implementing a threading mechanism in the kernel is going to be > > a whole lot easier then implementing async call gates. In fact, the > > whole KSE mechanism is going to be easier to implement if they are > > integrated into a native kernel-based threading mechanism. > > Under your proposal, is there a 1:1 correspondence of user (POSIX) > threads to kernel threads, or does the UTS simply see kernel threads > (instead of rfork'd processes) as the entity onto which user threads > are scheduled? > > In earlier email you had stated that kernel threads would be limited > to the resources of the governing process. One of our goals is to > be able to create thread groups that can have their own slice of > CPU, scheduling class and priority. How does this work under your > proposal? > > One of the things that I like about SA is that locking can be done > in userland because the UTS is notified when preemptions occur. Your > method doesn't include upcalls, so how would locking be done? > > Dan Eischen > eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 14:11: 3 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 A45DF14F94 for ; Wed, 1 Dec 1999 14:11:00 -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 XAA02008 for ; Wed, 1 Dec 1999 23:10:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA79024 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 23:10:37 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id E554414F94 for ; Wed, 1 Dec 1999 14:08:38 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id RAA11350; Wed, 1 Dec 1999 17:01:29 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id RAA95368; Wed, 1 Dec 1999 17:03:57 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <38459B4D.B922D168@vigrid.com> Date: Wed, 01 Dec 1999 17:03:57 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon , freebsd-arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> <199911301841.KAA26600@apollo.backplane.com> <38455430.C3CF72BD@vigrid.com> <199912011734.JAA34126@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: > > :Under your proposal, is there a 1:1 correspondence of user (POSIX) > :threads to kernel threads, or does the UTS simply see kernel threads > :(instead of rfork'd processes) as the entity onto which user threads > :are scheduled? > > Yes, there is a 1:1 correspondence. But the runnability of a thread > is controlled by the UTS, not the kernel. So, for example, if you > have 10 runnable threads and the UTS is implementing a serialized FIFO > scheduling class for all 10 threads,t he UTS will only tell the kernel > to schedule one thread at a time. If the UTS is implementing a > standard multi-processor model, the UTS will tell the kernel to schedule > N threads at a time, where N is the number of virtual cpu's the UTS > wishes to simulate. If N == X, where X is the actual number of cpu's > in the system, then the simulation happens to reflect reality. > > :In earlier email you had stated that kernel threads would be limited > :to the resources of the governing process. One of our goals is to > :be able to create thread groups that can have their own slice of > :CPU, scheduling class and priority. How does this work under your > :proposal? > > To get your own slice of CPU you can still rfork() just fine. That is, > rfork() can be done as a concious decision and does not need to be > done to simulate concurrency or to implement a *thread* scheduling class. OK suppose we rfork to get PTHREAD_SCOPE_SYSTEM threads or a different scheduling class. Is there still one "special management" thread or are there now two? The UTS needs to adjust scheduling of threads across the rfork'd processes. > :One of the things that I like about SA is that locking can be done > :in userland because the UTS is notified when preemptions occur. Your > :method doesn't include upcalls, so how would locking be done? > : > :Dan Eischen > :eischen@vigrid.com > > You can still do locking in userland. A userland lock simply calls the > UTS synchronously when it blocks. No upcall is required. Suppose a thread tries to take a lock and fails. It is suppose to make a synchronous call to the UTS to inform it that the thread is waiting on the lock? How does the UTS resolve the problem so that the owner of the lock (which the UTS may not know) continues to run until it releases the lock. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 14:28:56 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 519EC14C2D for ; Wed, 1 Dec 1999 14:28:51 -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 XAA02179 for ; Wed, 1 Dec 1999 23:28:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA79135 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 23:28:07 +0100 (MET) Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id D42D6151DF for ; Wed, 1 Dec 1999 14:25:39 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id OAA23422; Wed, 1 Dec 1999 14:23:52 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA24194; Wed, 1 Dec 1999 14:23:51 -0800 Received: from softweyr.com (dyn0.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA28444; Wed, 1 Dec 99 14:23:40 PST Message-Id: <38459FEF.B04F4617@softweyr.com> Date: Wed, 01 Dec 1999 15:23:43 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: "Richard Seaman, Jr." Cc: "Daniel M. Eischen" , arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> <19991130122423.N29767@tar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Richard Seaman, Jr." wrote: > > On Tue, Nov 30, 1999 at 12:38:51PM -0500, Daniel M. Eischen wrote: > > > I think we can perform thread switches totally in > > userland without any assistance from the kernel. > > This would be a big performance plus. Not if you want those threads to run on multiple processors in an SMP box. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 14:31:32 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 69D5C14A03 for ; Wed, 1 Dec 1999 14:31:29 -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 XAA02228 for ; Wed, 1 Dec 1999 23:31:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA79174 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 23:31:19 +0100 (MET) Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 02EF214BF4 for ; Wed, 1 Dec 1999 14:31:08 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id QAA24430; Wed, 1 Dec 1999 16:30:32 -0600 (CST) (envelope-from dick) Date: Wed, 1 Dec 1999 16:30:32 -0600 From: "Richard Seaman, Jr." To: Wes Peters Cc: "Richard Seaman, Jr." , "Daniel M. Eischen" , arch@freebsd.org Subject: Re: Threads stuff Message-ID: <19991201163032.G29767@tar.com> References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> <19991130122423.N29767@tar.com> <38459FEF.B04F4617@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <38459FEF.B04F4617@softweyr.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 01, 1999 at 03:23:43PM -0700, Wes Peters wrote: > "Richard Seaman, Jr." wrote: > > > > On Tue, Nov 30, 1999 at 12:38:51PM -0500, Daniel M. Eischen wrote: > > > > > I think we can perform thread switches totally in > > > userland without any assistance from the kernel. > > > > This would be a big performance plus. > > Not if you want those threads to run on multiple processors in an SMP box. I doubt you can eliminate all kernel calls for context switches when you have multiple processors, or even when you want multiple scheduler classes on UP. But, if you're only rescheduling a thread on the same KSE in response to a userland block or other event, then I can see this as possible, and as a win. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 14:49: 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 E7397151A8 for ; Wed, 1 Dec 1999 14:49:01 -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 XAA02383 for ; Wed, 1 Dec 1999 23:48:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA79271 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 23:48:11 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 87C2614E12 for ; Wed, 1 Dec 1999 14:48:04 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id RAA12030; Wed, 1 Dec 1999 17:40:26 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id RAA95420; Wed, 1 Dec 1999 17:42:45 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3845A464.6CA5B28A@vigrid.com> Date: Wed, 01 Dec 1999 17:42:44 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters Cc: "Richard Seaman, Jr." , arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> <19991130122423.N29767@tar.com> <38459FEF.B04F4617@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > "Richard Seaman, Jr." wrote: > > > > On Tue, Nov 30, 1999 at 12:38:51PM -0500, Daniel M. Eischen wrote: > > > > > I think we can perform thread switches totally in > > > userland without any assistance from the kernel. > > > > This would be a big performance plus. > > Not if you want those threads to run on multiple processors in an SMP box. Each cooperating subprocess has an upcall context and can perform switches for threads within the subprocess. So if you have multiple subprocesses and multiple CPUs, then you can have simultaneous thread switches occuring on each CPU. That's for async call-gates/SAs. Under Matts proposal, you don't need multiple subprocesses (rforks) in order to run simultaneously on multiple CPUs. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Dec 1 21: 7:35 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 3ED2814D63 for ; Wed, 1 Dec 1999 21:07:31 -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 GAA07142 for ; Thu, 2 Dec 1999 06:07:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA80659 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 06:07:25 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id E255914D49 for ; Wed, 1 Dec 1999 21:07:07 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA57954 for ; Thu, 2 Dec 1999 00:04:58 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Thu, 2 Dec 1999 00:04:58 -0500 (EST) From: Chuck Robey To: arch@freebsd.org Subject: Threads - kernel call costs In-Reply-To: <19991201085633.Z29767@tar.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 I'm reading more about threading strategies, and I realize a real comparison is going to depend very heavily on the real costs involved with getting the kernel to perform some basic tasks. From some things that Matt Dillon has said a little while back, I get the idea that there might even be some corners that might be cut, under the right conditions. I'm wondering at the costs involved in getting the kernel to do an upcall to a UTS. Also, what would the cost be, to get the kernel to do a context switch on a thread, given that there would be no switch in the memory area. I would also like to know the costs involved in installing signal handler masks, and vectors of signal handlers. I haven't seen enough on these topics, but one really can't come to any true conclusion on threading strategies without it. I'm not personally familiar with this, so I'm hoping others are. If you have more than one answer (say, if you give a range of 5 to 100 microseconds for something) then include reasons that would tend to make it be in the longer or shorter end of the range. Thanks. ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 9:10:12 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 2FA2414CA6 for ; Thu, 2 Dec 1999 09:10:06 -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 SAA17848 for ; Thu, 2 Dec 1999 18:10:02 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA83811 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 18:10:02 +0100 (MET) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0F59E14CAF for ; Thu, 2 Dec 1999 09:09:53 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p18-dn02kiryunisiki.gunma.ocn.ne.jp [210.163.200.115]) by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id CAA23442; Fri, 3 Dec 1999 02:09:33 +0900 (JST) Message-ID: <3846A720.2BA461A6@newsguy.com> Date: Fri, 03 Dec 1999 02:06:40 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Jake Burkholder Cc: "Daniel M. Eischen" , Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <19991127223909.22A511FCF@io.yi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jake Burkholder wrote: > > I'm just going from what Daniel said about libc_r having > to get the time of day and set the interval timer in > order to do a context switch, which can probably be > done in one system call. Either the context can be Mmmm... I though gettimeofday() was a very slow system call... I'll have to check that. -- Daniel C. Sobral (8-DCS) who is as social as a wampas dcs@newsguy.com dcs@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 9:41:32 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 2E80A14BFC for ; Thu, 2 Dec 1999 09:41:27 -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 SAA18128 for ; Thu, 2 Dec 1999 18:41:26 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA83943 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 18:41:25 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id 34BAA14C19 for ; Thu, 2 Dec 1999 09:40:10 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA02763; Thu, 2 Dec 1999 12:32:07 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA96507; Thu, 2 Dec 1999 12:34:30 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <3846ADA5.72017F25@vigrid.com> Date: Thu, 02 Dec 1999 12:34:29 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Jake Burkholder , Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <19991127223909.22A511FCF@io.yi.org> <3846A720.2BA461A6@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > Jake Burkholder wrote: > > > > I'm just going from what Daniel said about libc_r having > > to get the time of day and set the interval timer in > > order to do a context switch, which can probably be > > done in one system call. Either the context can be > > Mmmm... I though gettimeofday() was a very slow system call... I'll > have to check that. Where's the rest of this thread? Not to say that clock_gettime is any better, but gettimeofday was used probably because clock_gettime didn't/doesn't exist in FreeBSD-2.x. If anyone is going to be measuring context switch times of the current libc_r, please remember that there are at least a couple of extra system calls per thread switch (gettimeofday and setitimer). And if there are any threads doing I/O, there will be an additional poll(). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 12: 7:31 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 1575014EDC for ; Thu, 2 Dec 1999 12:07:21 -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 VAA19581 for ; Thu, 2 Dec 1999 21:07:14 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA85109 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 21:07:14 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id E096014E84; Thu, 2 Dec 1999 12:06:58 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame211.kame.net [203.178.141.211]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id FAA10802; Fri, 3 Dec 1999 05:06:52 +0900 (JST) To: freebsd-arch@freebsd.org Cc: cvs-committers@freebsd.org Subject: [Solicite review for KAME 3rd patch] X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991203050711F.shin@nd.net.fujitsu.co.jp> Date: Fri, 03 Dec 1999 05:07:11 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 22 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I prepared the 3rd KAME patch at the URL below, and would like to get comments for them. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/udp-for-ipv6-etc.19991203 Udp for IPv6 is added and several basic tools(ifconfig, route, netstat) become IPv6 ready. IPv6/IPv4 tunneling and IPv6/IPv4 translator related code in kernel is also added. But other tools including IPv6/IPv4 tunneling tool and IPv6/IPv4 translator daemon are not yet ready, because they require some IPv6 library functions. From this patch, INET6 kernel config options is stored in opt_inet6.h separately. I also cc'ing this mail to cvs-committers, because this time several userland tools are also patched. Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 12:14:38 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 7792F14EB9 for ; Thu, 2 Dec 1999 12:14:34 -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 VAA19651 for ; Thu, 2 Dec 1999 21:14:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA85148 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 21:14:29 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id C0D9F14EB9 for ; Thu, 2 Dec 1999 12:14:12 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40333>; Fri, 3 Dec 1999 07:06:19 +1100 Content-return: prohibited Date: Fri, 3 Dec 1999 07:13:46 +1100 From: Peter Jeremy Subject: Re: Threads stuff In-reply-to: <3846ADA5.72017F25@vigrid.com> To: eischen@vigrid.com, dcs@newsguy.com Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec3.070619est.40333@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991127223909.22A511FCF@io.yi.org> <3846A720.2BA461A6@newsguy.com> <3846ADA5.72017F25@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-03 04:34:29 +1100, Daniel M. Eischen wrote: >"Daniel C. Sobral" wrote: >> Mmmm... I though gettimeofday() was a very slow system call... I'll >> have to check that. ... >Not to say that clock_gettime is any better, On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and gettimeofday() takes 2.42usec - slightly better. Interestingly, in both cases about 30% of the time is charged as user rather than system - which suggests that either the kernel->user return is quite slow[*], or something odd is going on. I wouldn't consider either particularly slow (unless you count the clock cycles taken - around 650). Peter [*] Since the kernel entry and kernel exit are non-interruptable, any profiling interrupt will be delayed until the instruction is complete. Thus the kernel entry will be charged to the system, and the exit will be charged to the user. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 12:25:18 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 C72F014E0C for ; Thu, 2 Dec 1999 12:25:12 -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 VAA19760 for ; Thu, 2 Dec 1999 21:25:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA85208 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 21:25:11 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id AFD7014ECA for ; Thu, 2 Dec 1999 12:24:50 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA00821; Thu, 2 Dec 1999 21:22:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: peter.jeremy@alcatel.com.au Cc: eischen@vigrid.com, dcs@newsguy.com, arch@freebsd.org Subject: Re: Threads stuff In-reply-to: Your message of "Fri, 03 Dec 1999 07:13:46 +1100." <99Dec3.070619est.40333@border.alcanet.com.au> Date: Thu, 02 Dec 1999 21:22:54 +0100 Message-ID: <819.944166174@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <99Dec3.070619est.40333@border.alcanet.com.au>, Peter Jeremy writes: >On 1999-Dec-03 04:34:29 +1100, Daniel M. Eischen wrote: >On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and >gettimeofday() takes 2.42usec - slightly better. Interestingly, in >both cases about 30% of the time is charged as user rather than system >- which suggests that either the kernel->user return is quite slow[*], >or something odd is going on. > >I wouldn't consider either particularly slow (unless you count the >clock cycles taken - around 650). The time it takes depends on the "timecounter" you are using for your timekeeping. I will venture to guess that the above numbers come from a UP machine using the TSC. You can see which timecounter hardware you are using with the command: sysctl kern.timecounter.hardware If the timestamps don't need to be more precise than 1/hz, normally 10msec, there is an extremely fast facility available in the kernel which is currently not exported to userland. It could be exported as a read-only mapped page of memory which would make the call take only a few memory-accesses. For systems where the timecounter is the TSC (normally all Pentium and later non-SMP systems) A precise timestamp could be obtained the same way since the TSC can be read from userland. Let me know if this is worth working on... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 14:20:18 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 8031C14BD7 for ; Thu, 2 Dec 1999 14:20:09 -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 XAA20971 for ; Thu, 2 Dec 1999 23:19:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA85780 for freebsd-arch@freebsd.org; Thu, 2 Dec 1999 23:19:25 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C84F715099 for ; Thu, 2 Dec 1999 14:14:53 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA19402; Thu, 2 Dec 1999 15:14:47 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA05564; Thu, 2 Dec 1999 15:14:45 -0700 (MST) Message-Id: <199912022214.PAA05564@harmony.village.org> To: peter.jeremy@alcatel.com.au Subject: Re: Cross compilation goals. Cc: Terry Lambert , arch@freebsd.org In-reply-to: Your message of "Wed, 24 Nov 1999 08:14:34 +1100." <99Nov24.080748est.40328@border.alcanet.com.au> References: <99Nov24.080748est.40328@border.alcanet.com.au> <199911182348.QAA28898@harmony.village.org> <199911231916.MAA03270@usr06.primenet.com> Date: Thu, 02 Dec 1999 15:14:44 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <99Nov24.080748est.40328@border.alcanet.com.au> Peter Jeremy writes: : I'm not sure that being able to FreeBSD/alpha on DEC UNIX would help : any more than being able to build FreeBSD/alpha on FreeBSD/i386. : (Though at the time, I gather neither worked correctly). : : That said, my recent attempts to install FreeBSD on a Multia would : have be significantly simpler if I could have built netboot on : DEC UNIX. Yes. It is a much harder to do a cross build on Digital unix. I've tried in the past and have found that there are lots and lots of functions that are used that need a helper library which doesn't exist on dux. That's why I put the don't try for the non freebsd system initially. It complicates things quite a bit. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 15: 4:37 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 48DFA14C5A for ; Thu, 2 Dec 1999 15:04:30 -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 AAA21332 for ; Fri, 3 Dec 1999 00:04:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA85986 for freebsd-arch@freebsd.org; Fri, 3 Dec 1999 00:04:28 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BA22B14FD4 for ; Thu, 2 Dec 1999 15:03:47 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40342>; Fri, 3 Dec 1999 09:56:08 +1100 Content-return: prohibited Date: Fri, 3 Dec 1999 10:03:34 +1100 From: Peter Jeremy Subject: Re: Threads stuff In-reply-to: <819.944166174@critter.freebsd.dk> To: Poul-Henning Kamp Cc: arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Dec3.095608est.40342@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Dec3.070619est.40333@border.alcanet.com.au> <819.944166174@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Dec-03 07:22:54 +1100, Poul-Henning Kamp wrote: >In message <99Dec3.070619est.40333@border.alcanet.com.au>, Peter Jeremy writes: >>On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and >>gettimeofday() takes 2.42usec - slightly better. >The time it takes depends on the "timecounter" you are using for >your timekeeping. I will venture to guess that the above numbers >come from a UP machine using the TSC. Ooops, I forgot about that. Yes, this is an UP system using the TSC. AFAIK, I can't swap to the 8254 w/o rebooting. I tried the same thing on a P-133 using the i8254 and got: clock_gettime(CLOCK_REALTIME) 6.92 usec gettimeofday() 5.93 usec (And on a 386SX25 running 2.2.5, I got 115usec). >If the timestamps don't need to be more precise than 1/hz, I suspect that for the purposes in question, it _does_ need to be SMP safe (which writes off the TSC) and will need better than 1/hz precision (though I'm not definite about this). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Dec 2 15:14:28 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 84B4C14D30 for ; Thu, 2 Dec 1999 15:14:22 -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 AAA21406 for ; Fri, 3 Dec 1999 00:13:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA86053 for freebsd-arch@freebsd.org; Fri, 3 Dec 1999 00:13:17 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 51D1414C7F for ; Thu, 2 Dec 1999 15:12:46 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id AAA01593; Fri, 3 Dec 1999 00:11:52 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: peter.jeremy@alcatel.com.au Cc: arch@freebsd.org Subject: Re: Threads stuff In-reply-to: Your message of "Fri, 03 Dec 1999 10:03:34 +1100." <99Dec3.095608est.40342@border.alcanet.com.au> Date: Fri, 03 Dec 1999 00:11:52 +0100 Message-ID: <1591.944176312@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <99Dec3.095608est.40342@border.alcanet.com.au>, Peter Jeremy writes: >On 1999-Dec-03 07:22:54 +1100, Poul-Henning Kamp wrote: >>In message <99Dec3.070619est.40333@border.alcanet.com.au>, Peter Jeremy writes: >>>On my PII-266, clock_gettime(CLOCK_REALTIME) takes 2.48usec and >>>gettimeofday() takes 2.42usec - slightly better. > >>The time it takes depends on the "timecounter" you are using for >>your timekeeping. I will venture to guess that the above numbers >>come from a UP machine using the TSC. > >Ooops, I forgot about that. Yes, this is an UP system using the TSC. >AFAIK, I can't swap to the 8254 w/o rebooting. > >I tried the same thing on a P-133 using the i8254 and got: >clock_gettime(CLOCK_REALTIME) 6.92 usec >gettimeofday() 5.93 usec > >(And on a 386SX25 running 2.2.5, I got 115usec). > >>If the timestamps don't need to be more precise than 1/hz, > >I suspect that for the purposes in question, it _does_ need to >be SMP safe (which writes off the TSC) and will need better than >1/hz precision (though I'm not definite about this). It would be possible to make it optional, so that the routine would try to use the "all-in-userland" timekeeping only if available and resort to the kernel if not. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Dec 3 8: 6: 8 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 CD0B0151BE for ; Fri, 3 Dec 1999 08:06:02 -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 RAA08053 for ; Fri, 3 Dec 1999 17:05:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA89757 for freebsd-arch@freebsd.org; Fri, 3 Dec 1999 17:05:42 +0100 (MET) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6C9EF151BE for ; Fri, 3 Dec 1999 08:04:41 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA16013; Sat, 4 Dec 1999 03:10:49 +1100 Date: Sat, 4 Dec 1999 03:04:17 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Peter Jeremy Cc: Poul-Henning Kamp , arch@freebsd.org Subject: Re: Threads stuff In-Reply-To: <99Dec3.095608est.40342@border.alcanet.com.au> 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 Fri, 3 Dec 1999, Peter Jeremy wrote: > Ooops, I forgot about that. Yes, this is an UP system using the TSC. > AFAIK, I can't swap to the 8254 w/o rebooting. In -current, you can use sysctl -w kern.timecounter.hardware=i8254 sysctl -w kern.timecounter.hardware=TSC > I tried the same thing on a P-133 using the i8254 and got: > clock_gettime(CLOCK_REALTIME) 6.92 usec > gettimeofday() 5.93 usec That's surprisingly large. The difference is probably mainly due to different L1/L2 cache lossage. > (And on a 386SX25 running 2.2.5, I got 115usec). Heh. Some historical benchmarks for differences between successive calls to gettimeofday(): ==> /home/bde/current/var/microtime/go.cel-450 <== 1999/05/02: min 1, max 44, mean 1.683213, std 0.501948 1th: 2 (1359226 observations) 2th: 1 (639961 observations) 3th: 10 (286 observations) 4th: 11 (123 observations) 5th: 7 (116 observations) ==> /home/bde/current/var/microtime/go.cel-458 <== 1999/12/04: min 1, max 29, mean 1.498473, std 0.523034 1th: 1 (1008000 observations) 2th: 2 (991299 observations) 3th: 9 (253 observations) 4th: 10 (144 observations) 5th: 6 (106 observations) ==> /home/bde/current/var/microtime/go.dx2-66 <== 1995/11/03: min 13, max 171, mean 14.286634, std 1.836667 1th: 14 (1053245 observations) 2th: 15 (587593 observations) 3th: 13 (299847 observations) 4th: 16 (51817 observations) 5th: 33 (934 observations) ==> /home/bde/current/var/microtime/go.k6-233 <== 1998/02/21: min 2, max 124, mean 2.240976, std 0.617886 1th: 2 (1535123 observations) 2th: 3 (463782 observations) 3th: 18 (302 observations) 4th: 17 (234 observations) 5th: 19 (107 observations) ==> /home/bde/current/var/microtime/go.p5-133 <== 1996/07/12: min 3, max 472, mean 3.320346, std 0.694846 1th: 3 (1376420 observations) 2th: 4 (621949 observations) 3th: 12 (594 observations) 4th: 13 (281 observations) 5th: 11 (233 observations) 1998/02/21 pre-timecounter: min 3, max 595, mean 3.443382, std 0.767383 1th: 3 (1134768 observations) 2th: 4 (863276 observations) 3th: 15 (719 observations) 4th: 5 (299 observations) 5th: 16 (263 observations) 1998/02/21 post-timecounter: min 4, max 99, mean 4.614527, std 0.710407 1th: 5 (1195577 observations) 2th: 4 (801694 observations) 3th: 16 (707 observations) 4th: 6 (456 observations) 5th: 17 (420 observations) 1999/12/04: min 4, max 120, mean 4.630231, std 0.777733 1th: 5 (1222295 observations) 2th: 4 (775244 observations) 3th: 18 (444 observations) 4th: 19 (441 observations) 5th: 21 (250 observations) All except the dx2-66 used the TSC. We still haven't revovered the pre-timecounter performance. My current kernel has extra overheads to implement some monotonicity. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 4 6:49: 4 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 117E1153DB for ; Sat, 4 Dec 1999 06:48:53 -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 PAA29121 for ; Sat, 4 Dec 1999 15:48:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA97420 for freebsd-arch@freebsd.org; Sat, 4 Dec 1999 15:48:46 +0100 (MET) Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60]) by hub.freebsd.org (Postfix) with ESMTP id AEB5314FBE; Sat, 4 Dec 1999 06:48:30 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.197.22]) by smtp02.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA23BD; Sat, 4 Dec 1999 15:48:27 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id PAA03642; Sat, 4 Dec 1999 15:48:07 +0100 (CET) (envelope-from asmodai) Date: Sat, 4 Dec 1999 15:48:07 +0100 From: Jeroen Ruigrok/Asmodai To: Yoshinobu Inoue Cc: freebsd-arch@freebsd.org, cvs-committers@freebsd.org Subject: Re: [Solicite review for KAME 3rd patch] Message-ID: <19991204154807.G711@daemon.ninth-circle.org> References: <19991203050711F.shin@nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991203050711F.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Fri, Dec 03, 1999 at 05:07:11AM +0900 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Inoue-san, -On [19991203 00:00], Yoshinobu Inoue (shin@nd.net.fujitsu.co.jp) wrote: >I prepared the 3rd KAME patch at the URL below, and would like >to get comments for them. Here are my comments: [NOTE: all based on a clean extracted src from 09:00 GMT+1 cvsup sources] All patches succeeded on a fresh CURRENT source tree except for: - sbin/ifconfig/Makefile no .rej file was made curiously enough. Patched by hand. - sbin/route/Makefile no .rej file was made. Patched by hand. - usr.bin/netstat/Makefile also no .rej file. Patched by hand. sys/conf/files: I like the rearranging of the netinet options, it certainly clarifies things. sys/i386/conf/LINT: COMPATIBILITY OPTIONS seems to be a whitespace fix. Not needed IMHO. Does the gif comment imply that IPv4 in IPv4, IPv4 in IPv6, IPv6 in IPv4, IPv6 in IPv6 tunneling is supported? I think it does, but I wonder if others might not understand the notation used. One more comment line to clarify things from the start wouldn't hurt and would save questions to -questions. Also, use `gif' instead of `gif`, minor nitpick to remain consistent. The `faith` pseudo-device catches those packets which sent to it, and forwards then to IPv4 and IPv6 translating daemon. Should this be: The `faith' pseudo-device captures packets sent to it and forwards them to the IPv4/IPv6 translation daemon. Although I wonder if forwards could be changed to divert. Something which I wonder about is the removal of opt_inet.h in if.c. All other source files seem to retain their opt_inet.h alongside the opt_inet6.h. Was this intentional? Does faith replace loop? If so, what is against adding the IPv6 functionality to loop? if_fddisubr.c: contains a whitespace fix for netipx/ipx.h, not needed IMHO. Also contains whitespace fixes for llc_snap_*. Not needed. Same goes for senderr(), the else statement, the empty line `fix', register struct sockaddr_dl *sdl, the printf(" len 0x%x, the #endif, the #ifdef IPX and following #endif, #ifdef NETATALK, case LLC_ISO_LSAP, the other empty line `fix', fh->fddi_dhost, and the last empty line `fix'. Also, wouldn't it be better to follow INET6 directly after INET, since both are effectively the same protocol, except a different version? Just like you did with the #ifdef INET6 later on in this file. Later on with the ETHERTYPE cases, you now position yourself between NS and DECNET, why not follow directly after INET? if_gif.h: Numerous white space changes which are not needed and sometimes even revert the previous style(9) compliant code. Removal of the $FreeBSD$ doesn't seem needed. if_spppsubr.c: #define MAXALIVECNT is a whitespace change, the #define whitespace changes are not needed. Same goes for the */ `fix'. And another empty line `fix'. The IFF_CISCO whitespace fixes are also not needed. Some more #define and empty line whitespace `fixes'. if_atm.c: No need to touch the disclaimer for a whitespace fix. And aside fine the new #include does only whitespace fixes which are not needed. in_pcb.c: More tab/whitespace `fixes' aside from the new includes added and the #ifdef INET6's. in_pcb.h: Again, aside from one change, you shouldn't do whitespace fixes. in_proto.c: again a whitespace fix which shouldn't be in there. ip_fw.c: aside from changed function calls and the likes, more whitespace fixes. tcp_input.c: suffer from whitespace fixes. And the file suffers from continuous whitespace fixes. Find an update of your patch at http://home.wxs.nl/~asmodai/udp-for-ipv6-fixed.19991203 This update only fixes the whitespace problems for a couple files. I grew weary after file 16 or so. I compiled a world and got: cc -O -pipe -DKERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline - Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/usr/obj/usr/src/sys/modules/if_disc -I/usr/obj/usr/src/sys/modules/if_disc/@ -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/if_disc/../../net/if_disc.c /usr/src/sys/modules/if_disc/../../net/if_disc.c:55: opt_inet6.h: No such file or directory *** Error code 1 Stop in /usr/src/sys/modules/if_disc. My suggestion: checkout a new source tree and only modify that what you want to change and ignore tab line-ups and concentrate on the functionality. White space corrections are best done in cosmestic commits. Hope this helps, -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project Network/Security Specialist BSD: Technical excellence at its best Learn e-mail netiquette: http://www.lemis.com/email.html ...fools rush in where Daemons fear to tread. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 4 14:48:22 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 BD0B115303 for ; Sat, 4 Dec 1999 14:47:49 -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 XAA02599 for ; Sat, 4 Dec 1999 23:47:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA98917 for freebsd-arch@freebsd.org; Sat, 4 Dec 1999 23:47:09 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 6B70D14C28 for ; Sat, 4 Dec 1999 14:46:36 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id XAA01238; Sat, 4 Dec 1999 23:41:46 +0100 (CET) Date: Sat, 4 Dec 1999 23:41:45 +0100 From: Martin Cracauer To: Marcel Moolenaar Cc: Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991204234145.A1221@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" X-Mailer: Mutt 0.95.1i In-Reply-To: <382FF2AF.545C8C81@scc.nl>; from Marcel Moolenaar on Mon, Nov 15, 1999 at 12:46:55PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii I thought over the issue of mcontext and the need for additional status fields that the application's signal handler may use. The following proposal allows both compile-time and tun-time checks for the presense of fields in mcontext_t. Also mcontext_t is proposed to be bumped to 512 bytes for possible future extensions (because changing the size once 4.0 is out is *bad*). ********************************************************************** It is important that we agree on the scheme to use and the size of mcontext_t before the 4.0 codefreeze (15.12.1999)! ***************************************************************** Example usage of the field presence test scheme: An application wants to use the FPU status word saved in mcontext_t.save87.sv_ex_sw. #ifdef MCONTEXT_FPU if (mcontext->extensions & MCONTEXT_FPU) foo = mcontext->save87.sv_ex_sw; #endif That way, the following error will be caught correctly: - Application is being compiled on a system that doesn't have the field in mcontext -> #ifdef will be nil, field will not be accessed. - Application was compiled on a system which has save87 in mcontext, but is running on an older system that hasn't. The runtime test will be nil, the field will not be accessed. If the application just accessed the field, it would either coredump or get junk (probably contents of a different field). - Application was compiled and is running on a system that has save87 in struct mcontext, but the save87 space is not filled in this situation. The runtime test will fail. This would allow us to introduce a kernel option not to save the FPU over signal handlers. This runtime test capability may not look important for the FPU, but for other extensions that are more processor-specific it may make sense. What is not covered by this scheme is using the same space in mcontext for different purposes. This may be useful for example when some space is allowed *either* by some Pentium-III specific set of registers *or* some AMD-specific set of registers. My scheme would require that space for both is always allocated but only one (or none) is filled. To solve this, the scheme could be changed from the bitmap test to a set of pointers for the different fields (which may be NULL). #ifdef MCONTEXT_FPU if (mcontext->save87 != NULL) foo = mcontext->save87->sv_ex_sw; #endif That has higher runtime overhead (not so much for the application, but for the kernel at signal send time). And it will only save space when we actually have some big status blocks to share space, since we would need 16 (or so) pointers as an initial overhead (compared to 16 bits in the constant-place solution). As least the alpha folks will eat us alive, IMHO. Decisions in order of importance: - Do you accept bumping mcontext_t to 512 bytes? - Do you like the bitmap scheme? - If you would prefer the pointer scheme, you probably have some processor-specific things that may end up in mcontext. Tell us! The implementation I appended should work, but I'm sure some will hate the choice of field and macro names. These may be changed later, the former decisions are more urgent. The implementation appended doesn't really support access to the FPU for a different reason. No good scheme has been found so far to move the struct save87 definition into scope of the user's signal handler. But the appended diff does the actual preserving of FPU state over the signal handler (which is required for ANSI C). Comments welcome, of course Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="diff.savefpu-4" Index: i386/i386/machdep.c =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/i386/machdep.c,v retrieving revision 1.379 diff -c -r1.379 machdep.c *** machdep.c 1999/11/24 01:02:58 1.379 --- machdep.c 1999/12/04 21:34:09 *************** *** 632,637 **** --- 632,643 ---- sf.sf_uc.uc_mcontext.mc_gs = rgs(); bcopy(regs, &sf.sf_uc.uc_mcontext.mc_fs, sizeof(struct trapframe)); + /* Fill additional fields in mcontext. */ + sf.sf_uc.uc_mcontext.mc_extensions = 0; + bcopy(&p->p_addr->u_pcb.pcb_savefpu, sf.sf_uc.uc_mcontext.mc_fpregs, + sizeof(sf.sf_uc.uc_mcontext.mc_fpregs) + + sizeof(sf.sf_uc.uc_mcontext.mc_fpemul)); + /* Allocate and validate space for the signal handler context. */ if ((p->p_flag & P_ALTSTACK) != 0 && !oonstack && SIGISMEMBER(psp->ps_sigonstack, sig)) { *************** *** 959,964 **** --- 965,975 ---- } bcopy(&ucp->uc_mcontext.mc_fs, regs, sizeof(struct trapframe)); } + + /* Restore FPU state */ + bcopy(ucp->uc_mcontext.mc_fpregs, &p->p_addr->u_pcb.pcb_savefpu, + sizeof(ucp->uc_mcontext.mc_fpregs) + + sizeof(ucp->uc_mcontext.mc_fpemul)); if (ucp->uc_mcontext.mc_onstack & 1) p->p_sigstk.ss_flags |= SS_ONSTACK; Index: i386/include/signal.h =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/include/signal.h,v retrieving revision 1.12 diff -c -r1.12 signal.h *** signal.h 1999/11/12 13:52:11 1.12 --- signal.h 1999/12/04 21:39:37 *************** *** 106,118 **** int sc_efl; int sc_esp; int sc_ss; ! /* ! * XXX FPU state is 27 * 4 bytes h/w, 1 * 4 bytes s/w (probably not ! * needed here), or that + 16 * 4 bytes for emulators (probably all ! * needed here). The "spare" bytes are mostly not spare. ! */ ! int sc_fpregs[28]; /* machine state (FPU): */ ! int sc_spare[17]; }; #define sc_sp sc_esp --- 106,117 ---- int sc_efl; int sc_esp; int sc_ss; ! ! int sc_extensions; ! ! int sc_fpregs[28]; ! int sc_fpemul[16]; ! int __morespare__[63]; }; #define sc_sp sc_esp Index: i386/include/ucontext.h =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/include/ucontext.h,v retrieving revision 1.4 diff -c -r1.4 ucontext.h *** ucontext.h 1999/10/11 20:33:09 1.4 --- ucontext.h 1999/12/04 21:36:41 *************** *** 58,65 **** int mc_esp; /* machine state */ int mc_ss; int mc_fpregs[28]; /* env87 + fpacc87 + u_long */ ! int __spare__[17]; } mcontext_t; #endif /* !_MACHINE_UCONTEXT_H_ */ --- 58,84 ---- int mc_esp; /* machine state */ int mc_ss; + /* + * The following fields may or may not be present. An application + * will be able to compile-time test for the presence of + * individual field using #ifdefs and runtime-test using the bitmap + * in mc_extensions. + * + * While the infrastructure to use these fields from an application's + * signal handler is not yet implemented, we already reserve the space + * for the runtime-test bitmap. + * + * This is upward compatible since none of the individual #defines is + * defined and mc_extensions is zero for now. + */ + + /* Allow access to field mc_extensions. */ + #define MCONTEXT_EXTENSIONS + int mc_extensions; /* Bitmap of filled fields below */ + int mc_fpregs[28]; /* env87 + fpacc87 + u_long */ ! int mc_fpemul[16]; /* Additional FPU emulator status */ ! int __morespare__[63]; /* For later additions, total = 512 */ } mcontext_t; #endif /* !_MACHINE_UCONTEXT_H_ */ --J2SCkAp4GZ/dPZZf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Dec 4 14:54:29 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 C581E153A4 for ; Sat, 4 Dec 1999 14:53:58 -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 XAA02649 for ; Sat, 4 Dec 1999 23:53:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA98987 for freebsd-arch@freebsd.org; Sat, 4 Dec 1999 23:53:50 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id ADF73152D8 for ; Sat, 4 Dec 1999 14:53:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA11205; Sat, 4 Dec 1999 14:54:15 -0800 Date: Sat, 4 Dec 1999 14:54:15 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Martin Cracauer Cc: Marcel Moolenaar , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <19991204234145.A1221@cons.org> 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 Would any thinking about this be applicable to storing machine FPU specific state for Alpha or Sparc? In particular for Sparc there's a lot of userland fixup that can be done. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message