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