From owner-freebsd-arch Sun Dec 12 12:49: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 C87FD14CA2 for ; Sun, 12 Dec 1999 12:49: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 VAA25101 for ; Sun, 12 Dec 1999 21:49:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA50659 for freebsd-arch@freebsd.org; Sun, 12 Dec 1999 21:49:13 +0100 (MET) Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 9BCC414CC2 for ; Sun, 12 Dec 1999 12:49:00 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 8439 invoked by uid 1001); 12 Dec 1999 20:48:41 -0000 Date: Sun, 12 Dec 1999 12:48:41 -0800 From: Jason Evans To: "Daniel M. Eischen" Cc: Arun Sharma , arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <19991212124841.B350@sturm.canonware.com> References: <38539C2B.9632089A@vigrid.com> <19991212095553.A7995@sharmas.dhs.org> <3853F3C0.EE96FB16@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3853F3C0.EE96FB16@vigrid.com>; from eischen@vigrid.com on Sun, Dec 12, 1999 at 02:13:04PM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message