From owner-freebsd-arch Sun Dec 12 13:39: 0 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 5DF3714D19 for ; Sun, 12 Dec 1999 13:38: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 WAA25429 for ; Sun, 12 Dec 1999 22:38:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA50907 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 22:38:49 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BEE4F14DB8 for ; Sun, 12 Dec 1999 13:38:34 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id QAA22653; Sun, 12 Dec 1999 16:38:29 -0500 (EST) Message-ID: <385415BC.CA3DDDC4@vigrid.com> Date: Sun, 12 Dec 1999 16:38:04 -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: Jason Evans Cc: Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. References: <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org> <3853F3C0.EE96FB16@vigrid.com> <19991212124841.B350@sturm.canonware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > > On Sun, Dec 12, 1999 at 02:13:04PM -0500, Daniel M. Eischen wrote: > > Arun Sharma wrote: > > > Other concerns that were expressed - crossing protection boundaries too > > > often to pass messages about blocking and rescheduling. Matt Dillon > > > responded that these messages could be batched and made more efficient. > > > > I agree. It seemed like the SA paper went to extremes in notifying > > the UTS of unblocked threads. I think we can do this at more opportune > > times, like when a Q is resumed or on a user->kernel crossing. I don't > > know that we want to be interrupting a Q while it is running a thread > > just to notify the UTS that another thread has unblocked in the kernel. > > One aspect of the SA paper that we did not strictly adhere to in our design > is the idea that activations always upcall into the UTS. In particular, we > felt that it would work to restore a preempted activation rather than > creating a notification and a new activation. After re-reading the SA > paper (yet again), I'm not sure this saves us much performance-wise, and it > probably reduces flexibility. It is OK to resume a preempted activation only if you have one Q. The thing that makes SA work is that the UTS is informed about preemptions so threads can be resumed long enough to leave critical sections. Otherwise, with multiple Q's a preemption could make them all spin for their entire quantum until the preempted Q was finally resumed. And if you allow Q's to have their own priority, a low-priority Q that was preempted might hold up other Q's from running indefinitely. You _need_ preemption notification or else you have to use kernel level locks. I feel very strongly that we need preemption notification. Once you have the ability to make upcalls, it's no more difficult than any other upcall event. > > Another aspect of the SA paper that we did not adhere to is notification of > preemption. I'm not sure this is a good simplification. Without such > notifications, it is not possible to know what is or isn't running on other > processors, which could make certain scheduling decisions very difficult. > Then again, I don't like the idea of preempting an activation so that a > notification of preemption on another processor can be delivered. I agree. Wait until entering the kernel, or upon resuming from another preemption. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message