Date: Thu, 10 Jan 2002 15:16:17 -0800 (PST) From: Kelly Yancey <kbyanc@posi.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, Nate Williams <nate@yogotech.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <Pine.BSF.4.21.0201101449160.7081-100000@gateway.posi.net> In-Reply-To: <3C3E1870.1E0DA81F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0201101449160.7081-100000>