Date: Sun, 12 Dec 1999 13:01:21 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Jason Evans <jasone@canonware.com> Cc: "Daniel M. Eischen" <eischen@vigrid.com>, Arun Sharma <adsharma@sharmas.dhs.org>, arch@freebsd.org Subject: Re: Recent face to face threads talks. Message-ID: <Pine.BSF.4.10.9912121256500.26823-100000@current1.whistle.com> In-Reply-To: <19991212124841.B350@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As a general commnet I think that teh 'simplifications' we discussed were basically because we couldn't see easy ways of doing them, or at least not without rewriting large amounts of stuff. I don't think what we talked about precludes any of these things, but that we didn't feen it was important enough to make them out primary objective. The decision that we would allow a process (Q) that had been involuntarily pre-empted to continue with the KSE/thread it was running before teh pre-emption is a simplification because it requires no work where calling the UTS could in fact require a lot of work. However we don't PRECLUDE someone fromd oing that work in the future. On Sun, 12 Dec 1999, 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. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912121256500.26823-100000>