Date: Mon, 29 Nov 1999 11:54:24 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-arch@freebsd.org Subject: Re: Which is the truth? (sycalls and traps) (fwd) Message-ID: <99Nov29.114712est.40340@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.10.9911281554080.544-100000@current1.whistle.com> References: <99Nov29.103530est.40344@border.alcanet.com.au> <Pine.BSF.4.10.9911281554080.544-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Nov29.114712est.40340>