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