From owner-freebsd-arch Thu Jan 10 14:41: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 02FA737B41D for ; Thu, 10 Jan 2002 14:41:00 -0800 (PST) Received: from pool0272.cvx22-bradley.dialup.earthlink.net ([209.179.199.17] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16OnsR-0002ZJ-00; Thu, 10 Jan 2002 14:40:52 -0800 Message-ID: <3C3E1870.1E0DA81F@mindspring.com> Date: Thu, 10 Jan 2002 14:40:48 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kelly Yancey Cc: Alfred Perlstein , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kelly Yancey wrote: > If the context switch overhead is the same (or worse) with a userland > scheduler, then what are the "effeciency reasons" for having it? Where does > the userland scheduler reclaim it's lost ground? The only things my limited > understanding can produce are a number of trivial data structures that can be > moved from the kernel to userland. :/ > It seems to me that if {get,set}context involve kernel calls, then any > userland scheduler would, by definition, require N+1 context switches where N > is the number of context switches required by a kernel-only scheduler. The > extra 1 coming from invoking the scheduler context itself. Remember that this is only true if someone is stupid enough to use the FPU, which is only useful for very specific tasks, most of which are non-threaded. For graphics and line drawing -- even curve drawing -- the fast graphics world all uses integer math and tables. That leave us with special purpose number crunching that doesn't care incredibly deeply about its significant digits running away to exponent&mantissa-land. If a system call *is* required, it can be done conditionally in a wrapper function that knows whether or not there's an FPU in user space, or not. > The flexibility argument I can buy, given as a trade-off of performance > versus flexibility. However, I do not see where having a mixed > kernel/userland scheduler can be both more flexible and more efficient in the > case that it requires a syscall to switch userland contexts. And it doesn't > seem proper to keep the flexibility argument if {get,set}context only work > with our specific implementation of libc_r (as Peter has already noted). You could make a similar argument based on signal masks, which are all overly complicated because the default signal behaviour in POSIX is to *not* restart system calls. A much better idea is to simply change the default behaviour, and the problem goes away, outside the presence of a siginterrupt() call, or an sa_flags explicitly clearing SA_RESTART, or a longjmp(). > Of course, all this moot if userland context switches can be done properly > without entering the kernel and in a way the preserves flexibility. > > As an aside, I cannot find a reference now, but hasn't it been rumoured that > Solaris has dropped it's userland scheduler? No, Solaris *added* one around 2.4; see the comp.unix.bsd archives, where I and a number of other people, including Sun engineers, were discussing threads implementation inefficiencies in Solaris/SVR4, starting in around 1993 and continuing for a number of years after that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message