From owner-freebsd-arch Thu Jan 10 15:16:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 481CD37B446 for ; Thu, 10 Jan 2002 15:16:20 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110231619.XUAG3578.rwcrmhc52.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 23:16:19 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0ANGHS07201; Thu, 10 Jan 2002 15:16:18 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 15:16:17 -0800 (PST) From: Kelly Yancey To: Terry Lambert Cc: Alfred Perlstein , Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3E1870.1E0DA81F@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 10 Jan 2002, Terry Lambert wrote: > 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. > Line and curve drawing a *so* passe, the graphics world has gone 3D, Terry. :) One big debate that recurs amongst game programmers is whether to use floats or doubles. :) You may be correct that few Unix apps use floating point, but in the non-Unix world people have recognized that modern floating point units are pretty darn speedy and, when the precision isn't important, it's nice to divert some work off the main instruction pipelines. Chip designers haven't been throwing silicon at FPUs for years for nothing. But that's off-topic. :) > 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. > Then we have a solution. Alfred already presented a simple interface for the kernel to tell userland whether the FPU state needs saving. Personally, I think the flag should be considered an opaque "kernel has state to save" flag rather than a specific "FPU state needs saving" flag, but that's neither here nor there. > > > 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(). > You could, but I don't think anyone considered letting freebsd-arch decide whether POSIX would mandate defaulting to restarting system calls. :) It sounds like you are leaning toward implementing context saving/restoring syscalls, which save or restore the entire context respectively. Then, the getcontext() library function would only call the save syscall if the kernel indicated (i.e. via Alfred's proposed interface) that there was saved FPU state (or more generically, state not visible to userland); getcontext() would have to record this fact in the context buffer. Then setcontext() could examine the context buffer and if a full context restore is needed, call the restore context syscall, otherwise it may restore itself. Is this an accurate assessment? > > 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 Again, I apologize, this is likely my poor recollection. For some reason I was thinking the userland scheduler was removed in the 2.8 timeframe, but Nate may be correct and that I'm thinking of the alternate 1:1 scheduler. Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message